218792 - can we change to linking against libc-2.2.3

Status: RESOLVED EXPIRED

(Firefox Build System :: General, enhancement)

Description

[Jens Elkner]

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
./mozilla-bin)



Expected Results:  
link against libc-2.2.3, which is probably at this time still the most
used libc version on desktop systems.

Comment 1

[Matthias Versen [:Matti]]

doesn't block development

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[tenthumbs]

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 
artifact.

Comment 4

[Jens Elkner]

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
./mozilla-bin)

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

[Andrew Schultz]

>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
help.

Comment 6

[tenthumbs]

> 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

[tenthumbs]

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

[Andrew Schultz]

"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

[tenthumbs]

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 {
  global:
    dl_iterate_phdr;
    getgrouplist;
    sockatmark;
}

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

[Jens Elkner]

Just an update: The problem exist in 1.5rc1 (mozilla-installer-bin,
mozilla-bin) as well ...

Comment 11

[(default assignee for unassigned bugs. does not receive bugmail)]

Mass reassign of Build/Config bugs to Leaf.

Comment 12

[Andrew Schultz]

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.

Comment 13

[Gervase Markham [:gerv]]

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/

Comment 14

[Gervase Markham [:gerv]]

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.