[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[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:
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
const struct r_found_version *version = &l->l_versions[ndx];

This could happen in glibc 2.2.5

----- End forwarded message -----

Reply to: