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.
