[rhelv6-list] static linking and glibc

[Peter Ruprecht]

John Haxby wrote:
> 
> 
> On 14 September 2011 17:10, Peter Ruprecht 
> <peter.ruprecht at jila.colorado.edu 
> <mailto: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
> 

I just tried a few other functions in simple statically-linked programs 
and so far as I can tell only gethostbyname is causing the problem.

What started this exercise is a statically-linked 3rd-party application 
that works fine in RHEL 5 but crashes in gethostbyname on RHEL 6.  The 
vendor believes it's a glibc bug in RHEL 6, rather than an issue with an 
incompatible version of glibc being dynamically loaded at runtime to 
service the necessary functions.  At this point I'm inclined to agree, 
since bug 597578 has been fixed in FC 14 and above, and the 3rd-party 
app works fine in FC 14 and above.

So I have opened a bugzilla report: 
https://bugzilla.redhat.com/show_bug.cgi?id=739184

Thank you very much for your input and suggestions.

  -Peter