This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: 2.2.94 Problem
- From: Andreas Jaeger <aj at suse dot de>
- To: Greg Schafer <gschafer at zip dot com dot au>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Sun, 22 Sep 2002 07:28:00 +0200
- Subject: Re: 2.2.94 Problem
- References: <20020922050658.GA25447@tigers-lfs.nsw.bigpond.net.au>
Greg Schafer <gschafer@zip.com.au> writes:
> Hi
>
> I'm trying to actually use the library instead of just compiling it
> and running make check.
>
> I don't really know what I'm doing so I'm just throwing this onto the
> list in case someone finds it interesting.
>
> Apologies if this is irrelevant to glibc.
>
> The problem is that a statically linked bash shell (compiled on a
> glibc-2.2.5/gcc-3.2 system) segfaults immediately when executed inside a
> chroot env with 2.2.94 installed.
>
> The steps I'm taking:-
>
> * compiling a bunch of statically linked stuff (compiler, tools, utils,
> shell etc) and installing them into a prefix
> * chroot'ing into that prefix then proceed to build up the rest of the
> system by starting with glibc
>
> Those steps have worked perfectly for me for years.
>
> This is i686-pc-linux-gnu on kernel 2.4.19 using 2.4.19 headers.
>
> The starting (host) system is:-
> glibc-2.2.5 (with bits from 2.2.6) and --enable-kernel=current
> gcc-3.2
> binutils-2.13
> bash-2.05a
>
> The versions for the chroot system are:-
> glibc-2.2.94 (with __hidden_dot_def1 fix otherwise it wouldn't build)
> gcc-3.2.1 cvs
> binutils-2.13.90.0.4
> bash-2.05a
>
> It happens with bash-2.05a or 2.05b. I include a trace below but it is
> pretty well useless.
>
>
> Core was generated by `/static/bin/bash'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x080ef09a in elf_machine_rel.0 ()
> (gdb) bt
> #0 0x080ef09a in elf_machine_rel.0 ()
> #1 0x080ef34a in elf_dynamic_do_rel.4 ()
> #2 0x080ef4eb in _dl_relocate_object ()
> #3 0x080e93d1 in dl_open_worker ()
> #4 0x080d4ee4 in _dl_catch_error ()
> #5 0x080e94e6 in _dl_open ()
> #6 0x080d593a in do_dlopen ()
> #7 0x080d4ee4 in _dl_catch_error ()
> #8 0x080d58f2 in dlerror_run ()
> #9 0x080d59c9 in __libc_dlopen ()
> #10 0x080ce767 in __nss_lookup_function ()
> #11 0x080ce3c0 in __nss_lookup ()
bash needs the shared libnss_* libraries and searches for them. It
seems to get them from your older glibc and those two do not work
together.
> #12 0x080ca7c4 in getpwuid_r ()
> #13 0x080ca2b2 in getpwuid ()
> #14 0x08049bcd in get_current_user_info () at shell.c:1491
> #15 0x08049e2c in shell_initialize () at shell.c:1549
> #16 0x08048570 in main (argc=1, argv=0xbffffc54, env=0xbffffc5c) at shell.c:507
> #17 0x080a97ed in __libc_start_main ()
>
>
> Greg
>
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj