On Wednesday, 26 February 2014 at 17:08:38 UTC, Assaf Gordon wrote:
> In my first message in this thread, I wrote (item #3), that unless I'm missing something, there is no way to build a statically linked binary with D on Linux.

They really aren't far from it out of the box:

$ dmd hellod.d
$ ldd hellod
        linux-gate.so.1 =>  (0xffffe000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf76db000)
        libm.so.6 => /lib/libm.so.6 (0xf76b5000)
        librt.so.1 => /lib/librt.so.1 (0xf76ac000)
        libc.so.6 => /lib/libc.so.6 (0xf7549000)
        /lib/ld-linux.so.2 (0xf7730000)


It isn't fully static, but those libraries are all pretty basic things and generally available on any linux install. The biggest problem is probably the libc version not matching on older installations.

One option might be to package those .so files right with your executable. A poor man's static link.


Anyway, let's try the -static switch we can use to do statically linked libc on some programs.

$ dmd hellod.d -c
$ gcc hellod.o -o hellod -m32 -L/home/me/d/dmd2/linux/bin32/../lib32 -Xlinker --export-dynamic -l:libphobos2.a -lpthread -lm -lrt -static

undefined reference to `__tls_get_addr'


BTW if you run "dmd -v yourfile.d" the last line of output is the linker command line it runs (via gcc). Then you can copy/paste that and tweak the arguments. Here, I added -static.


However, that is *not* a D problem per se, that's a libc function. Maybe my system just doesn't have the right stuff installed to build a static threaded app.

> I would gladly spend the time to create VMs for each common system setup and package a static binary for it.


If you're doing that, you don't need to do anything special, since the vm will link the appropriate libc version anyway, so the default build should work.


I betcha if I sent you my binary from my slackware box over to your computer it would work even if you are a different distro.

On 02/26/2014 12:34 PM, Adam D. Ruppe wrote:
> On Wednesday, 26 February 2014 at 17:08:38 UTC, Assaf Gordon wrote:
>> In my first message in this thread, I wrote (item #3), that unless I'm missing something, there is no way to build a statically linked binary with D on Linux.
>
> They really aren't far from it out of the box:
>
> $ dmd hellod.d
> $ ldd hellod
>          linux-gate.so.1 =>  (0xffffe000)
>          libpthread.so.0 => /lib/libpthread.so.0 (0xf76db000)
>          libm.so.6 => /lib/libm.so.6 (0xf76b5000)
>          librt.so.1 => /lib/librt.so.1 (0xf76ac000)
>          libc.so.6 => /lib/libc.so.6 (0xf7549000)
>          /lib/ld-linux.so.2 (0xf7730000)
>
>
> It isn't fully static, but those libraries are all pretty basic things and generally available on any linux install. The biggest problem is probably the libc version not matching on older installations.

This might seem "generally available" on linux, but it's not.
It might be "generally available" when you assume you're dealing with "recent" "desktop" versions of linux.
But it's not at all when dealing with servers (as Artem already mentioned before: http://forum.dlang.org/post/mailman.290.1393304990.6445.digitalmars-d@puremagic.com ) .

As a quick example, try to download and run the pre-compiled binaries of "ldc2" from the dlang.org website on a Stable Debian - they will fail with incompatible libc versions.

>
> One option might be to package those .so files right with your executable. A poor man's static link.
>

Now that's what I'd call "windows attitude" - package all dependencies together, in what I think was termed "DLL hell" :)

I think that low-level libraries (e.g. ld-linux, libc, linux-gate, librt, libpthread) are tightly coupled to the system (and the kernel), you really don't want to run incompatible ones on an arbitrary linux system.


>
> Anyway, let's try the -static switch we can use to do statically linked libc on some programs.
>
> $ dmd hellod.d -c
> $ gcc hellod.o -o hellod -m32 -L/home/me/d/dmd2/linux/bin32/../lib32 -Xlinker --export-dynamic -l:libphobos2.a -lpthread -lm -lrt -static
>
> undefined reference to `__tls_get_addr'
>
>
> BTW if you run "dmd -v yourfile.d" the last line of output is the linker command line it runs (via gcc). Then you can copy/paste that and tweak the arguments. Here, I added -static.
>
>
> However, that is *not* a D problem per se, that's a libc function. Maybe my system just doesn't have the right stuff installed to build a static threaded app.
>

I'd argue the opposite: it is a D problem (or libphobos2/druntime problem, which is a major part of D).

The missing symbol "__tls_get_addr" is referenced from the D function getTLSRange() in "druntime/src/rt/sections_linux.d".
And the way druntime uses it is apparently not compatible with static linking (I know very little about this low-level stuff).

>
>
> I betcha if I sent you my binary from my slackware box over to your computer it would work even if you are a different distro.

You'd be surprised what kind of old versions of linuxes are out there.
I have tried it with C-based projects, and based on my humble experience, anything except a real static binary will eventually cause problems to users.

On Wednesday, 26 February 2014 at 17:34:45 UTC, Adam D. Ruppe wrote:
> Anyway, let's try the -static switch we can use to do statically linked libc on some programs.
>
> $ dmd hellod.d -c
> $ gcc hellod.o -o hellod -m32 -L/home/me/d/dmd2/linux/bin32/../lib32 -Xlinker --export-dynamic -l:libphobos2.a -lpthread -lm -lrt -static
>
> undefined reference to `__tls_get_addr'

Huh, I was sure this works. Unpleasant surprise.

Have filed a bug report : https://d.puremagic.com/issues/show_bug.cgi?id=12268

( I don't have time to properly answer holy war topics, probably later :) )

On Wednesday, 26 February 2014 at 18:52:55 UTC, Assaf Gordon wrote:
> It might be "generally available" when you assume you're dealing with "recent" "desktop" versions of linux.

I've had good luck with them on my servers too but I haven't used many of the distros.

But I have had the same libc version problems you see too.

> I think that low-level libraries (e.g. ld-linux, libc, linux-gate, librt, libpthread) are tightly coupled to the system (and the kernel), you really don't want to run incompatible ones on an arbitrary linux system.

If this were true, static linking would be useless! Static linking is basically just copying the library functions into your binary instead of leaving a reference to the library.

> I'd argue the opposite: it is a D problem (or libphobos2/druntime problem, which is a major part of D).

I'm not sure because searching the web for people having this problem with C++ suggests the fix is to update the libc on their development computer. So that might work with us too.... but then again if it breaks on your computer too who knows.

> I have tried it with C-based projects, and based on my humble experience, anything except a real static binary will eventually cause problems to users.

I agree, this is why I prefer distributing Windows exes :) but if you know your target computers it might not be a big problem, just compile with a libc close enough to them.