From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 K-Meleon/0.9 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): glibc-2.3.3-68 How reproducible: Always 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 Segmentation fault Expected Results: Program should have run Additional info:
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 2.6.8.1 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.