This is the mail archive of the libc-alpha@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

FAQ entry



Since the release of glibc 2.1, I've seen a lot of mails like the
following: 
> I compiled and installed the glibc 2.1 libraries on my machine at home.. 
> and then I used 'ldconfig' to link
> the new libraries... this turned out to be a Bad Thing(tm)... now, with 
> EVERY program (with the exception of about 4) gives
> something along the lines of:
> 
> error in loading shared libraries:  libc.so.6: unresolved symbol: 
> _ld_initial_searchlist  -- (I think its searchlist)

Is there any way we could tie libc and ld-linux tighter together?
Currently, we expect that both have the same version - otherwise the
above error occurs.  Is there a way to output a better warning
message, e.g. with defining a variable in libc.so, that must match one
in ld.so (and if not abort with the error message "this dynamic linker
has version 2.0.7 and expects libc version 2.0.7 and not 2.1") ?

For now, I'd like to answer with the appended FAQ.  What do you think
of it?  Uli, could you add it to glibc, please?

Andreas

??	After upgrading to glibc 2.1, I receive errors about
unresolved symbols, like `_dl_initial_searchlist' and can not execute
any binaries.  What went wrong?

{AJ} This normally happens if you try to run dynamic linker and libc
from different versions of glibc.  For example: The dynamic linker
/lib/ld-linux.so.2 comes from glibc 2.0.x but the used libc.so.6 is
the one from glibc 2.1.

The path /lib/ld-linux.so.2 is hardcoded in every glibc2 binary but
libc.so.6 is searched via /etc/ld.so.cache and in some special
directories like /lib and /usr/lib.  If you run configure with another 
prefix than /usr and put this prefix before /lib in /etc/ld.so.conf,
your system will break.

So what can you do?  Either of the following should work:

* Run `configure' with the same prefix argument you've used for glibc
  2.0.x so that the same paths are used.
* Replace /lib/ld-linux.so.2 with a link to the dynamic linker from
  glibc 2.1.

You can even call the dynamic linker by hand if everything fails, e.g.

	LD_LIBRARY_PATH=<path-where-libc.so.6-lives> \
	<path-where-corresponding-dynamic-linker-lives>/ld-linux.so.2 \
	<path-to-binary>/binary

With that command line no path is used.  To further debug problems
with the dynamic linker, use the LD_DEBUG environment variable, e.g.
`LD_DEBUG=help echo' for the help text.

If you just want to test this release, don't put the lib directory in
/etc/ld.so.conf.  You can call programs directly with full paths (as
above).  For compiling new programs against glibc 2.1, you've got to
specify the correct paths to the compiler (option -I with gcc) and
linker (options --dynamic-linker,-L and --rpath=).

-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]