John Haxby wrote:
On 14 September 2011 17:10, Peter Ruprecht
<[email protected]
<mailto:[email protected]>> 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
_______________________________________________
rhelv6-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv6-list
