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

Bug#445507: not working on mipsel - initrd not starting



On Sat, Oct 20, 2007 at 09:52:52PM +0200, Bastian Blank wrote:
> On Sat, Oct 20, 2007 at 09:18:24PM +0200, Bastian Blank wrote:
> > | $ ./lib/ld.so.1 --library-path lib/ ./bin/sh
> > | Segmentation fault
> 
> | $ LD_LIBRARY_PATH=lib/ ./bin/sh
> | 
> | 
> | BusyBox v1.1.3 (Debian 1:1.1.3-5) Built-in shell (ash)
> | Enter 'help' for a list of built-in commands.
> 
> | $ /lib/ld.so.1 --library-path lib/ ./bin/sh
> | Segmentation fault
> 

The problem comes from the following symbols in libc.so.6

00000000 l       *UND*  00000000              .hidden __nss_aliases_database
00000000 l       *UND*  00000000              .hidden __nss_rpc_database
00000000 l       *UND*  00000000              .hidden __nss_ethers_database
00000000 l       *UND*  00000000              .hidden __nss_netgroup_database
00000000 l       *UND*  00000000              .hidden __nss_shadow_database
00000000 l       *UND*  00000000              .hidden __nss_publickey_database

Those symbols are glibc symbols that are not used within the reduced 
libc. They are exported as undefined on all architectures, though they
are defined in libc_p.a.

On most architectures, they do not cause any problem, but on mips and
mipsel ld.so seems to be confused and segfault during the relocation
phase. Thiemo, do you have an idea about what can lead to segfault?

Also note that in Etch those symbols were also undefined, but not
hidden. I guess this is the reason why mklibs stopped working.

A quick workaround is to mark those functions as used by using the -u
options from gcc as it is done for other symbols. It only increase the
size of libc.so.6 by a few kilobytes, and I have tested that it actually
works correctly.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net



Reply to: