Hello all,

I've run into a nasty little issue with `std.net.curl` and ldc v1.0.0.  If I build v1.0.0 freshly from source, and then use it to compile the following tiny program:

////////////////////////////////////////////////

void main ()
{
    import std.net.curl : get;
    auto website = "http://dlang.org/".get;
}

////////////////////////////////////////////////

... the program compiles correctly, but when I run it, I get a segfault.  A stacktrace is given here:
https://forum.dlang.org/post/cxfrbiwccxdnmrkuufwe@forum.dlang.org

This doesn't however occur if I build my program with the pre-built ldc v1.0.0 downloadable from GitHub.

I'm guessing this is in some way related to the fact that as of ldc v1.0.0, libcurl.so is dynamically loaded at runtime rather than being linked to phobos at build time.  So this makes me wonder: is there something extra required when building LDC that I might be missing?  I note that dmd now automatically links against libdl in order to support dynamic loading of libraries:
https://github.com/dlang/dmd/commit/541d9b61cd1792535cd4c99c418b42273bb9baa5

... so could I be missing something similar when building LDC?

I note that if I manually link in -ldl when compiling my program above, it makes no difference to the segfault.

Can anyone advise what could be wrong?

Thanks & best wishes,

    -- Joe

On Monday, 26 September 2016 at 18:52:04 UTC, Joseph Rushton Wakeling wrote:
>
> So this makes me wonder: is there something extra required when building LDC that I might be missing?

Just a very quick reply, perhaps it can help you:
https://github.com/ldc-developers/ldc-scripts/tree/master/ldc2-packaging
we use this git repo to store the scripts that are used to build the binary packages.

(which platform are you on?)

On Monday, 26 September 2016 at 19:03:37 UTC, Johan Engelen wrote:
> Just a very quick reply, perhaps it can help you:
> https://github.com/ldc-developers/ldc-scripts/tree/master/ldc2-packaging
> we use this git repo to store the scripts that are used to build the binary packages.

Thanks!  I notice that on Linux you use a -DCMAKE_EXE_LINKER_FLAGS='-static-libstdc++' that I'm not using.  I'll give that a try.

> (which platform are you on?)

Ubuntu 16.04.  I'm using the distro-packaged dependencies, with llvm 3.8.

On Monday, 26 September 2016 at 19:20:04 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 26 September 2016 at 19:03:37 UTC, Johan Engelen wrote:
>> Just a very quick reply, perhaps it can help you:
>> https://github.com/ldc-developers/ldc-scripts/tree/master/ldc2-packaging
>> we use this git repo to store the scripts that are used to build the binary packages.
>
> Thanks!  I notice that on Linux you use a -DCMAKE_EXE_LINKER_FLAGS='-static-libstdc++' that I'm not using.  I'll give that a try.

Hmm, makes no apparent difference :-(

On Monday, 26 September 2016 at 19:49:46 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 26 September 2016 at 19:20:04 UTC, Joseph Rushton Wakeling wrote:
>> On Monday, 26 September 2016 at 19:03:37 UTC, Johan Engelen wrote:
>>> Just a very quick reply, perhaps it can help you:
>>> https://github.com/ldc-developers/ldc-scripts/tree/master/ldc2-packaging
>>> we use this git repo to store the scripts that are used to build the binary packages.
>>
>> Thanks!  I notice that on Linux you use a -DCMAKE_EXE_LINKER_FLAGS='-static-libstdc++' that I'm not using.  I'll give that a try.
>
> Hmm, makes no apparent difference :-(

Just to share more details on my system:

  * Ubuntu 16.04
  * llvm-3.8-dev
  * libconfig++9v5 1.5-02
  * gcc 5.4.0
  * libedit 3.1
  * zlib 1.2.8

I don't really have an idea here, but I'd try a few things to narrow it down - e.g., replace your druntime/Phobos libs by the pre-built ones and see if that makes it work, then try using the ldc2.conf from the prebuilt one, then the ldc2 executable itself etc.

On Tuesday, 27 September 2016 at 17:49:58 UTC, kinke wrote:
> I don't really have an idea here, but I'd try a few things to narrow it down - e.g., replace your druntime/Phobos libs by the pre-built ones and see if that makes it work, then try using the ldc2.conf from the prebuilt one, then the ldc2 executable itself etc.

Good call.  If I replace druntime with the pre-built one, then things work OK with the built curl-using program.  Switching out phobos makes no difference.

On Tuesday, 27 September 2016 at 18:34:41 UTC, Joseph Rushton Wakeling wrote:
> Good call.  If I replace druntime with the pre-built one, then things work OK with the built curl-using program.  Switching out phobos makes no difference.

This is quite interesting, because the backtrace suggests the segfault is happening in gc.gc.Gcx.smallAlloc:
https://forum.dlang.org/post/cxfrbiwccxdnmrkuufwe@forum.dlang.org

On Tuesday, 27 September 2016 at 18:34:41 UTC, Joseph Rushton Wakeling wrote:
> If I replace druntime with the pre-built one, then things work OK with the built curl-using program.  Switching out phobos makes no difference.

Oh this may make things clearer. druntime features C parts, so the pre-built one and yours probably differ in the used C(++) runtime; the malloc issue also points in this direction. As we seem to be using libstdc++, are you sure you're using that one too?

On Tuesday, 27 September 2016 at 21:00:03 UTC, kinke wrote:
> Oh this may make things clearer. druntime features C parts, so the pre-built one and yours probably differ in the used C(++) runtime; the malloc issue also points in this direction. As we seem to be using libstdc++, are you sure you're using that one too?

That would make sense.  How would I determine whether or not I'm using libstdc++?

I note that the build scripts for Linux pass cmake a flag:

    -DCMAKE_EXE_LINKER_FLAGS='-static-libstdc++'

when I tried this, I had to pass instead:

    -DCMAKE_EXE_LINKER_FLAGS='-L-static-libstdc++'

... otherwise I got a linker failure for the ldc2 build with the message that there was no such option as 'tic-libstdc++' (!).

Since in any case I'm building on Ubuntu 16.04 rather than the 12.04 used to create the prebuilt package, I presume libstdc++ would be a different version (I can't verify exactly which right now, I'm afraid, as I'm currently away from my computer), which I suppose could reasonably be the reason for the problem.