[lars.oppermann@sun.com: Re: [dev] Crash on startup]
Here's the real cause of all those strange relocation errors:
----- Forwarded message from Lars Oppermann <lars.oppermann@sun.com> -----
Date: Mon, 24 Feb 2003 13:11:03 +0100
From: Lars Oppermann <lars.oppermann@sun.com>
Subject: Re: [dev] Crash on startup
To: dev@openoffice.org
Hi Ken
Ken Foskey wrote:
>/home/ken/.OpenOffice.org644/program/soffice.bin: relocation error:
>/home/ken/.OpenOffice.org644/program/libsvx644li.so: symbol
>_ZN22SvxStyleToolBoxControl6UpdateEv, version GLIBC_2.0 not defined in
>file libm.so.6 with link time reference
>
>gcc 3.2.3
I presume you are using glibc 2.3.1 (or at least some post 2.2.5
release). There is a bug in that glibc versions which we only discovered
during the last two weeks, this will make lookups for simbols in
libraries with more than 2^15 exported symbols fail. The glibc
maintainers have been notified and this is already fixed in the glibc
CVS (elf/dl-runtime.c).
For now, you can set LD_BIND_NOW=1 as a workaround, however this will
slow down your openoffice startup.
Which exact glibc version are you using, I have only verified the bug to
be in glibc 2.3.1 and not to be in 2.2.5...
Some background on what is happening:
When a call to a symbol (non virtual), that is not yet resolved is to be
made, a dummy 'trampoline' function in ld.so is called to resolve the
symbol so the call can be 'redirected' the first part of this is done in
a system dependant function, that sets up the information about the
symbol that is to be resolved and than calls fixup() from
elf/dl-runtime.c which will find out in which object to look for the
symbol and then call the resolving function...
fixup() will also take care about version information that is stored in
elf libraries. To get the version-table index for a symbol the following
is done:
(elf/dl-runtime.c:87)
ElfW(Half) ndx = vernum[ELFW(R_SYM) (reloc->r_info) & 0x7fff];
So for symbols whose 'index' in the shared object is greater than 2^15,
we will 'wrap around' and get the version-index for the 'symindex mod
2^15)th symbol, which in this case happen to be the index for GLIBC_2.0.
The line has to read:
ElfW(Half) ndx = vernum[ELFW(R_SYM) (reloc->r_info)] & 0x7fff;
since the version table 'only' holds 2^15 entries...
Otherwise, line 88 could read behind link_map.l_versions
(elf/dl-runtime.c:88)
const struct r_found_version *version = &l->l_versions[ndx];
This could happen in glibc 2.2.5
Bests,
~Lars
----- End forwarded message -----
Reply to: