On Linux, how do I get DMD to statically link against the necessary system libs like libc?

Someone suggested trying -L-static, but that just gives me this:

/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
--- errorlevel 1

> On Linux, how do I get DMD to statically link against the necessary system libs like libc?
> 
> Someone suggested trying -L-static, but that just gives me this:
> 
> /usr/bin/ld: cannot find -lgcc_s
> collect2: ld returned 1 exit status
> --- errorlevel 1

http://d.puremagic.com/issues/show_bug.cgi?id=4376

You're stuck, linking manually with gcc, which means copying all of the appropriate linker flags from dmd.conf. It also means that you don't get symbols in your stack traces for some reason (I've never been able to figure out why). It does work though. Still, I'd love it if this bug could be fixed. I hate dynamically linking anything if I can help it.

- Jonathan M Davis

On Tue, 26 Apr 2011 14:49:56 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

>> On Linux, how do I get DMD to statically link against the necessary system
>> libs like libc?
>>
>> Someone suggested trying -L-static, but that just gives me this:
>>
>> /usr/bin/ld: cannot find -lgcc_s
>> collect2: ld returned 1 exit status
>> --- errorlevel 1
>
> http://d.puremagic.com/issues/show_bug.cgi?id=4376
>
> You're stuck, linking manually with gcc, which means copying all of the
> appropriate linker flags from dmd.conf. It also means that you don't get
> symbols in your stack traces for some reason (I've never been able to figure
> out why). It does work though. Still, I'd love it if this bug could be fixed.
> I hate dynamically linking anything if I can help it.

It's a bad idea to statically link libc.  This is from the glibc maintainer:

http://www.akkadia.org/drepper/no_static_linking.html

I don't think static linking is officially supported any more.

-Steve

On 26/04/2011 19:09, Nick Sabalausky wrote:
> On Linux, how do I get DMD to statically link against the necessary system
> libs like libc?
>
> Someone suggested trying -L-static, but that just gives me this:
>
> /usr/bin/ld: cannot find -lgcc_s
> collect2: ld returned 1 exit status
> --- errorlevel 1
>
>
As I suggest in the other thread you probably shouldn't ever do it. In the same way you shouldn't (and can't) statically link to kernel32 on windows.

I forget exactly, but you could try this, don't put any extra -L or anything, like you appear to have above.

-static  -static-libgcc

it's possible perhaps that you don't have the static libgcc installed on your system, seems a bit unlikely, though.

On 26/04/2011 20:10, Steven Schveighoffer wrote:
...

>
> I don't think static linking is officially supported any more.
It is but only for OS binaries. Some systems infact, like AIX and Windows, do no support it at all.

i.e. linking to kernel32.dll statically, this is what you are asking for, and remember libc calls into the kernel like kernel32.dll does, its more than just a c library despite it's name.

Ok, so I guess statically linking against the stuff isn't the way to go, and apparently DLL hell is worse on linux. Sooo...What do I do?

In the other thread, Spacen said: "The way to do this is to link against the
oldest libc you need to
support, thus making the binaries forward compatible"

I know my way around Linux as a user, but with deeper system stuff like that I'm pretty much lost. I don't have a clue how to do what Spacen suggests or how to determine what version of libc I need. Can anyone help me out with that?

On Tue, 26 Apr 2011 16:28:22 -0400, Nick Sabalausky <a@a.a> wrote:

> Ok, so I guess statically linking against the stuff isn't the way to go, and
> apparently DLL hell is worse on linux. Sooo...What do I do?
>
> In the other thread, Spacen said: "The way to do this is to link against the
> oldest libc you need to
> support, thus making the binaries forward compatible"
>
> I know my way around Linux as a user, but with deeper system stuff like that
> I'm pretty much lost. I don't have a clue how to do what Spacen suggests or
> how to determine what version of libc I need. Can anyone help me out with
> that?

It's been a while since I had to deal with old libs, but usually a linux distro will provide 'compatibility' versions of the standard libraries.

Look for packages using your package manager that end with compat

-Steve

On 04/26/2011 02:28 PM, Nick Sabalausky wrote:
> Ok, so I guess statically linking against the stuff isn't the way to go, and
> apparently DLL hell is worse on linux. Sooo...What do I do?
>
> In the other thread, Spacen said: "The way to do this is to link against the
> oldest libc you need to
> support, thus making the binaries forward compatible"
>
> I know my way around Linux as a user, but with deeper system stuff like that
> I'm pretty much lost. I don't have a clue how to do what Spacen suggests or
> how to determine what version of libc I need. Can anyone help me out with
> that?
>
>

Can you backup, and help me understand what the first problem was? The one you thought was solvable by statically linking against glibc?

-Kai Meyer

"Kai Meyer" <kai@unixlords.com> wrote in message news:ip9bro$1lak$1@digitalmars.com...
> On 04/26/2011 02:28 PM, Nick Sabalausky wrote:
>> Ok, so I guess statically linking against the stuff isn't the way to go,
>> and
>> apparently DLL hell is worse on linux. Sooo...What do I do?
>>
>> In the other thread, Spacen said: "The way to do this is to link against
>> the
>> oldest libc you need to
>> support, thus making the binaries forward compatible"
>>
>> I know my way around Linux as a user, but with deeper system stuff like
>> that
>> I'm pretty much lost. I don't have a clue how to do what Spacen suggests
>> or
>> how to determine what version of libc I need. Can anyone help me out with
>> that?
>>
>>
>
> Can you backup, and help me understand what the first problem was? The one you thought was solvable by statically linking against glibc?
>

It was the thread "D CGI test: linux.so.2: bad ELF interpreter: No such file or directory".

Reposted here:

-------------------------

I've made a little test CGI app:

import std.conv;
import std.stdio;

void main()
{
 auto content = "<b><i>Hello world</i></b>";
 auto headers =
`HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: `~to!string(content.length);

 while(readln().length > 1) {}

 writeln(headers);
 writeln();
 writeln(content);
}

Works on Windows command line and through IIS. And it works on my Kubuntu
10.6 (CORRECTION: It's v10.04) command line. But if I copy the executable
from my Kubuntu box to my
web host's Debian server (CORRECTION: It's Red Hat, but there is another
server I'd like to also run on that is Debian): Running it through Apache
gives me a 500, and running it directly with ssh gives me:

linux.so.2: bad ELF interpreter: No such file or directory

I assume that error message is the cause of the 500 (can't tell for sure because the 500 isn't even showing up in my Apache error logs). But I'm not enough of a linux expert to have the slightest clue what that error message is all about. I don't need to actually compile it *on* the server do I? I would have thought that all (or at least most) Linux distros used the same executable format - especially (K)Ubuntu and Debian.

On 27/04/2011 18:51, Nick Sabalausky wrote:
> "Kai Meyer"<kai@unixlords.com>  wrote in message
> news:ip9bro$1lak$1@digitalmars.com...
>> On 04/26/2011 02:28 PM, Nick Sabalausky wrote:
>>> Ok, so I guess statically linking against the stuff isn't the way to go,
>>> and
>>> apparently DLL hell is worse on linux. Sooo...What do I do?
>>>
>>> In the other thread, Spacen said: "The way to do this is to link against
>>> the
>>> oldest libc you need to
>>> support, thus making the binaries forward compatible"
>>>
>>> I know my way around Linux as a user, but with deeper system stuff like
>>> that
>>> I'm pretty much lost. I don't have a clue how to do what Spacen suggests
>>> or
>>> how to determine what version of libc I need. Can anyone help me out with
>>> that?
>>>
>>>
>>
>> Can you backup, and help me understand what the first problem was? The one
>> you thought was solvable by statically linking against glibc?
>>
>
> It was the thread "D CGI test: linux.so.2: bad ELF interpreter: No such file
> or directory".
>
> Reposted here:
>
> -------------------------
>
> I've made a little test CGI app:
>
> import std.conv;
> import std.stdio;
>
> void main()
> {
>   auto content = "<b><i>Hello world</i></b>";
>   auto headers =
> `HTTP/1.1 200 OK
> Content-Type: text/html; charset=UTF-8
> Content-Length: `~to!string(content.length);
>
>   while(readln().length>  1) {}
>
>   writeln(headers);
>   writeln();
>   writeln(content);
> }
>
> Works on Windows command line and through IIS. And it works on my Kubuntu
> 10.6 (CORRECTION: It's v10.04) command line. But if I copy the executable
> from my Kubuntu box to my
> web host's Debian server (CORRECTION: It's Red Hat, but there is another
> server I'd like to also run on that is Debian): Running it through Apache
> gives me a 500, and running it directly with ssh gives me:
>
> linux.so.2: bad ELF interpreter: No such file or directory
>
> I assume that error message is the cause of the 500 (can't tell for sure
> because the 500 isn't even showing up in my Apache error logs). But I'm not
> enough of a linux expert to have the slightest clue what that error message
> is all about. I don't need to actually compile it *on* the server do I? I
> would have thought that all (or at least most) Linux distros used the same
> executable format - especially (K)Ubuntu and Debian.
>
>
>
Yes well hmm. I've done this type of thing before, that is want to make something run on newer systems. And lo and behold our makefile used static linking with libc, so I can say authoritatively that in certain circumstances it does not work. (it it only going to work without doubt if you run it on the exact same system)

I've just been to court today (small claims) and it's been a hard day, so before I rant on, can you tell us what version you want to run said binary on (distro and version) and what version you are compiling on.


As an example, to solve this problem I have compiled on redhat 2ES and all binaries now work on redhat 2-3-4 ubuntu 10.10 and so on, i.e. those that are later in generation than redhat 2. And it all works fine.

This is what I suggest, if it is possible. i.e. compile on redhat 2, or perhaps 3.

Perhaps if you post your build system version and flavour and target system I'll be able to give you a better answer.

try lsb_release for this, if you aren't sure (and it's available as a command)

jason@ionrift:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.2 LTS
Release:        10.04
Codename:       lucid

otherwise cat /etc/*release*