If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

can we change to linking against libc-2.2.3




Build Config
14 years ago
8 years ago


(Reporter: Jens Elkner, Unassigned)


1.0 Branch

Firefox Tracking Flags

(Not tracked)




14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Since all betas and more recent versions of mozilla are linked against
libc-2.2.4 a lot of users are unable to test mozilla >= 1.3, since
they have 2.2.3 or less, only.

E.g. Slackware 8.0.0 comes with libc-2.2.3 and was installed on our companie's
desktops in the middle of 2001. Certainly just because of mozilla no one
wants to start to reinstall/upgrade all systems ... 

Reproducible: Always

Steps to Reproduce:
1. Install slackware 8.0.0
2. Install Mozilla >= 1.4
3. Try to start mozilla

Actual Results:  
./mozilla-bin: /lib/libc.so.6: version `GLIBC_2.2.4' not found (required by

Expected Results:  
link against libc-2.2.3, which is probably at this time still the most
used libc version on desktop systems.
doesn't block development
Severity: blocker → normal


14 years ago
Severity: normal → enhancement
Summary: link with libc-2.2.3 required → can we change to linking against libc-2.2.3
I think what happened is the build machines switched from being Red Hat 6.x to
being Red Hat 7.x, and the glibc requirement is the glibc version of the machine
that does the builds.  But I could be wrong...

Comment 3

14 years ago
I think the first thing to do is find out which symbol is causing 
problems. Reporter: from an xterm can you try this command

 env LD_DEBUG=symbols mozilla 2>&1 |tee ld.log

and see which symbols are the problem. Then it's a question of whether 
mozilla really need that functionality or if it's, perhaps, some Redhat 

Comment 4

14 years ago
elkner.h58-307 /usr/apps/mozilla-1.5b > ./mozilla-bin
./mozilla-bin: /lib/libc.so.6: version `GLIBC_2.2.4' not found (required by

That's all (LD_DEBUG=symbols is set and displays stuff for other progs). 
I think, this is a loader problem and can only be fixed by either upgrading
to a higher libc/loader version :(( or to compile mozilla with ver. 2.2.3 

Comment 5

14 years ago
>objdump -x mozilla-bin | grep "2\.2"
    0x09691a74 0x00 07 GLIBC_2.2.4
0805750c       F *UND*  000000c1              dl_iterate_phdr@@GLIBC_2.2.4

That symbol doesn't show up in Mozilla source (according to lxr), but shows up
in /usr/include/link.h on my RH9 system.

libxpcom.so also requires 2.2.4, but the lib is stripped, so objdump isn't much

Comment 6

14 years ago
> I think, this is a loader problem

Maybe not. I compiled mozilla on a Slackware 8.1 system which uses an
unmodified glibc 2.2.5 (although I used gcc 3.3) and no executable or
shared library references dl_iterate_phdr. The next time I build I'll
use the slack 8.1 live cdrom and verify with an original system.

Either glibc changed between 2.2.4 and 2.2.5 (not indicated in the
change logs) or this is a Redhat artifact. Someone should check if 
Redhat patched their code.

If this really is a Redhat issue then I think mozilla should consider 
building nightlies on a more generic distribution, i.e. doesn't patch 
its sources except for known bug fixes.

> objdump isn't much help.

FWIW, nm -D will dump the dynamic symbols and readelf -V will dump 
versioning info.

Comment 7

14 years ago
OK, dl_iterate_phdr appears to be used only by unwind-dw2-fde-glibc.c 
While a version exists in glibc both gcc 3.2.3 and 3.3 have their own 
versions in libgcc_eh.a. I've tried both of these compilers but the 
symbol dl_iterate_phdr never appears in the ELF objects. It's possible 
that the compiler mozilla uses was built in a way that requires this 
whereas my compilers do not.

It's also possible that something else is bringing in this symbol. Some 
parts of the mozilla nightlies were built with the infamous gcc 2.96 so 
who knows.

Comment 8

14 years ago
"nm -D" says libxpcom.so also contains dl_iterate_phdr.  It might contain other
relevant symbols, but nm doesn't get version info on the symbols.

Comment 9

14 years ago
A lot of the shared libraries contain that suymbol. Looking through the 
glibc version scripts, these are the only functions tagged 2.2.4:

GLIBC_2.2.4 {

so dl_iterate_phdr is the most likely culprit. It's just a helper
function for C++ exception handling, so why is it there? My gcc 3.2.3 
and 3.3 builds do not include it when I build mozilla.

Comment 10

14 years ago
Just an update: The problem exist in 1.5rc1 (mozilla-installer-bin,
mozilla-bin) as well ...
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf

Comment 12

13 years ago
FYI: current trunk builds are not linked against 2.2.4 (the highest GLIBC symbol
version is 2.2)... except for libqfaservices.so (talkback).  If you remove or
just move that lib out of your components directory, you should be able to use
the build.


13 years ago
Assignee: leaf → cmp
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Last Resolved: 12 years ago
Resolution: --- → EXPIRED


8 years ago
Assignee: chase → nobody
Component: Build Config → Build Config
Product: SeaMonkey → Core
QA Contact: build-config
Version: Trunk → 1.0 Branch
You need to log in before you can comment on or make changes to this bug.