[rhelv6-list] static linking and glibc

John Haxby john.haxby at gmail.com
Wed Sep 14 21:21:13 UTC 2011


On 14 September 2011 17:10, Peter Ruprecht <peter.ruprecht at jila.colorado.edu
> wrote:
>
> I seem to be able to reproduce in RHEL 6 the bug reported in
> https://bugzilla.redhat.com/**show_bug.cgi?id=597578<https://bugzilla.redhat.com/show_bug.cgi?id=597578>.  I have glibc-static 2.12-1.25.el6_1.3 installed.
>
> Before I open a bugzilla report on this, I just want to check the wisdom of
> the community on whether it really is a bug, or whether it's just an
> expected manifestation of the "don't static link with glibc" model (a la
> http://people.redhat.com/**drepper/no_static_linking.html<http://people.redhat.com/drepper/no_static_linking.html>.)
>
>
In the past when I've found people trying to statically link with glibc, the
problems have revolved around things like gethostbyname() failing because
they can't dynamically load the relevant library.

This doesn't look like that: it's a failure somewhere within malloc().   Can
you open a file for reading with a very small static program (e.g.
fopen("/etc/passwd", "r") and not a lot else)?  Or just malloc() a buffer?

Having said that, I'm not at all keen on glibc static linking.   I'm
surprised it works at all (to produce something that can be executed), but,
of course, you're baking in any security problems or bugs that might be
fixed in a future version and if you're planning to distribute the resultant
binary then you have licensing issues to worry about.  I would expect that
Ulrich's web page goes into more detail, but you need to be sure that
dynamic linking is going to fix more problems than it solves.   (I had a
couple of people convinced that you couldn't debug an executable unless it
was static.   That might've been true a decade or more ago on HP/UX, but
it's not true now.)

Interestingly, compiling that example program on F15 gives this warning:

/tmp/cc4822Uz.o: In function `main':
foo.c:(.text+0x15): warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc version
used for linking

And indeed, running it under strace shows it dynamically loading a library
in order to do the gethostbyname().   So it's not as static as you might
think it is.    The executable is also 832KB, unstripped, and size tells me
that it's 780KB so it's going to take a hell of a long time to load compared
to the dynamic version although, of course, once it's cached it's pretty
quick.  On the other hand, the dynamic program is 6.5KB unstripped and size
says it's actually a little less than 2KB.

jch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20110914/19036cc3/attachment.htm>


More information about the rhelv6-list mailing list