Red Hat Bugzilla – Bug 136027
Static linked binaries are seg faulting
Last modified: 2007-11-30 17:10:52 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3)
Description of problem:
With the latest glibc version, static linked binaries are seg
faulting. Regular dynamic linked binaries are working fine.
Backing out glibc to glibc-2.3.3-53 fixes the problem, and once again
the binaries work correctly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade to latest glibc-2.3.3-68
2. Try to run any static linked binary
Actual Results: [root@everest ~]# ldd `which mysql`
not a dynamic executable
[root@everest ~]# mysql
Expected Results: Program should have run
While this bug doesn't make much sense (and the filer has admitted it
on irc) , it's filed by somebody whose observation skills I tend to trust.
Wonder if it's got anything to do with prelink and/or non-PIE binaries
breaking, or something else getting in the way ?
If FC3's current libc somehow breaks statically linked binaries from
3rd parties, this might be a showstopper.
OK, the gdb output I got on irc makes a little more sense. Looks like
the static binary he has tries to load the vsyscall page ...
<Bruns> Reading symbols from shared object read from target
memory...(no debugging symbols found)...done.
<Bruns> Loaded system supplied DSO at 0xffffe000
<Bruns> Program received signal SIGSEGV, Segmentation fault.
<Bruns> 0x00000000 in ?? ()
No debugging symbols so no backtrace ... but the DSO looks obvious.
<Bruns> this is a stock 220.127.116.11 kernel
ok, another crucial data point...
Created attachment 105334 [details]
static compiled bash which is seg faulting
This is one of the multiple static binaries on the system which seg fault when
the glibc is updated. I can attach more if necessary
Old static binaries that may use NSS (which bash can, e.g. for ~user
lookups) are not guaranteed to work unless you supply them with the
exact libnss* DSOs from the glibc version originally linked with.
If this is the only problem, this is not something we will change.
If there is a problem with freshly made static binaries, or static
binaries that do not use any dynamic modules at all, then we can look
into it. But that would need a recipe to make such a binary from
source. We cannot just use unknown binaries you give us.
Sounds like an item for the release notes - though admittedly I don't
know enough about glibc to tell for sure...
Roland, if this indeed a release note worthy item, would you mind
writing up a paragraph or so for the FC3 release notes ? ;)
This is not a new or one-time issue. It is a specified limitation of
using static linking with glibc. It should already be documented
somewhere, since it's been true of static linking with glibc since 2.0.
Furthermore, when linking such statically linked applications,
linker already warns about this, e.g.:
warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
I'll note that the breakage is gone with glibc-2.3.3-73, and the
static binaries that were seg faulting are now running fine again.