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.
