Linux: How to statically link against system libs?

[Spacen Jasset]

On 29/04/2011 01:46, Alexander wrote:
> On 26.04.2011 21:44, Spacen Jasset wrote:
>
>> 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.
>
>    Windows does - there are static versions of C runtime and some others. Linux libc is not really very special, it only provides nice interface to syscalls.
That's because in windows the syscalls and the c libraries are in 
different libraries.

You still *cannot* link statically to kernel32.dll. That's the 
difference. Linux glibc contains the C library functions *and* the 
syscalls, which is the bit that causes the problems.

msvcrt.dll and msvcrt.lib don't have any syscalls in them. they call 
though kernel32.dll dynamically.

The answer therefore on linux as it is on windows: do not to statically 
link anything that calls the kernel, which in this case is glibc

Arguably the ability to link statically to libc should be removed from 
the compiler as it seems to confuse everyone as to what is actually 
happening and what the outcome will be.


>
>    Actually, static linking is useful sometimes, and it is not always possible to link dynamically.
>
>    Example: Fedora 14 and CentOS 5.5 shared libs are incompatible, though static binaries run on both - flawlessly. The main problem is that some dependencies are not satisfied through compatibility layer, as not all libs provide that (like libxml2 or
> some other), thus, building on CentOS wouldn't really help (unless everything but libc will be linked statically anyway). Linux is now in "DLL hell" more than any Windows ever...
>
>    And, by the way, D can be used for OS binaries as well ;) Though, I would look into direction of uClibc - smaller footprint and almost the same functionality, and it can be safely linked statically.
>
> /Alexander

I don't know about any of that. All I say is software was built on 
Centos 3 and it runs on the then company I was working for supported 
platforms.

Which is redhat 3,4,5 + and Suse 9.something + That is 32bit and 64 bit 
by the way too.

It also runs on ubuntu (since about version 6ish +, upto 10, and I dare 
say beyond) and fedora, but rekon it hasn't been tried recently on 
Fedora 14 as it's not a supported platform. This all happens from one 
binary compiled on Centos 3


There was a bug, that I had to fix, and that was a crash on something 
like Redhat 4, because at the time libc was being statically linked. I 
can't remember the syscall that caused problem now, I have a feeling it 
was BSD sockets related.

libc is designed to be forward compatible only, if you dynamically link 
it. The symbols within are versioned and the correct ones bound at runtime.

I pipe up about all this because I've been though it all, and did not 
understand at the time what was wrong with static linking, but then you 
see the difference between Posix type platforms and windows, and what 
libc *actually is*, then it all makes sense.