Glibc hell

[Spacen Jasset]

Steven Schveighoffer wrote:
> "Spacen Jasset" wrote
>> Steven Schveighoffer wrote:
>>> You may have to statically link (which, of course, is not officially 
>>> supported by glibc, for very stupid reasons).
>> I am not sure that the reasons are "stupid". It is similar, for example to 
>> kernel32.dll on windows, which you cannot link to statically *at all* libc 
>> is a comparable interface in that it calls into the kernel.
> 
> The reasons are not so concrete.  It's more a matter of opinion than 
> requirement.
> 
> For example, see this web page: 
> http://people.redhat.com/drepper/no_static_linking.html
> 
> I ran into this when trying to get busybox working.  It took me a while to 
> figure out, but I ended up using a dynamic glibc.  Apparently, there are 
> bugs in glibc with static linking that the developers refuse to fix because 
> "static linking glibc isn't a valid requirement."
> 
> Yet some very important programs are statically linked.  For example, 
> ldconfig and  nash (Red Hat's system loader shell).  It just seems stupid to 
> me when they preach that you should *always* dynamically link, yet there are 
> cases where they found it more suitable to statically link.
> 
> Just my opinion.
> 
> -Steve 
> 
> 
It is the way it is at the end of the day. I don't consider it too 
unreasonable to require dynamic linking for things such as glibc. 
(again, just like kernel32.dll and user32.dll on windows)

At our company we compile against older versions of glib c and the same 
code runs without problem on the latest versions. This is not the case 
with static linking it often breaks unless you run on the same system 
you linked on.

As for bugs in glibc preventing static linking I can't comment except to 
say that the the kernel apis do sometimes change and I have read that 
static linking will case crashes, which it does. It appears they don't 
want to maintain static compatibility in this way. However, if you do 
build glibc from source there is a configurable option to provide 
compatability wrappers, I noticed this when building a cross compiler.

I know that static linking of glibc is sometimes used so that the 
libraries are not required for base operating system components, in 
particular some maintenance binaries are linked in this way so that a 
system can be recovered without the need for a working usable /usr/lib 
directory.

Unfortunately it does seem easier to compile against an older glibc 
using an older distribution, but there may be a better way. Installing 
an older gcc may suffice. At our company we took the "easy way" and used 
a virtual machine.

For us Linux DMD users a bug should be raised against dmd so that Walter 
will hopefully compile against an older glibc on future releases.