summary refs log tree commit diff
path: root/FAQ
diff options
context:
space:
mode:
authorUlrich Drepper <drepper@redhat.com>1999-02-11 14:59:52 +0000
committerUlrich Drepper <drepper@redhat.com>1999-02-11 14:59:52 +0000
commit5ff1a70a0fe9c3ce3b675e7fced1b6d63ed8547b (patch)
tree74a5ec4fb8f91e200b65df7c7cf86d0ef71d2f82 /FAQ
parent49b75f5ef5da3136e4b4015e23e2fe38aacbc7b3 (diff)
downloadglibc-5ff1a70a0fe9c3ce3b675e7fced1b6d63ed8547b.tar.gz
glibc-5ff1a70a0fe9c3ce3b675e7fced1b6d63ed8547b.tar.xz
glibc-5ff1a70a0fe9c3ce3b675e7fced1b6d63ed8547b.zip
Update.
1999-02-11  Ulrich Drepper  <drepper@cygnus.com>

	* localedata/locale/in_ID: New file.

1999-02-11  Andreas Schwab  <schwab@issan.cs.uni-dortmund.de>

	* sysdeps/wordsize-64/inttypes.h: Always define ldiv_t if not yet
	defined.

	* sysdeps/wordsize-32/inttypes.h: Always define lldiv_t if not yet
	defined.
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ47
1 files changed, 47 insertions, 0 deletions
diff --git a/FAQ b/FAQ
index 84e8796ecf..b60a1b3c97 100644
--- a/FAQ
+++ b/FAQ
@@ -136,6 +136,9 @@ please let me know.
 3.16.	Why has <netinet/ip_fw.h> disappeared?
 3.17.	I get floods of warnings when I use -Wconversion and include
 	<string.h> or <math.h>.
+3.18.	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?
 
 4. Miscellaneous
 
@@ -1416,6 +1419,50 @@ ignore the warnings.
 -Wconversion isn't really intended for production use, only for shakedown
 compiles after converting an old program to standard C.
 
+
+3.18.	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 your libc and ld (dynamic linker) are from
+different releases of glibc.  For example, the dynamic linker
+/lib/ld-linux.so.2 comes from glibc 2.0.x, but the version of libc.so.6 is
+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.  You've
+got to set LD_LIBRARY_PATH so that the corresponding libc is found and also
+need to provide an absolute path to your binary:
+
+	LD_LIBRARY_PATH=<path-where-libc.so.6-lives> \
+	<path-where-corresponding-dynamic-linker-lives>/ld-linux.so.2 \
+	<path-to-binary>/binary
+
+For example `LD_LIBRARY_PATH=/libold /libold/ld-linux.so.2 /bin/mv ...'
+might be useful in fixing a broken system (if /libold contains dynamic
+linker and corresponding libc).
+
+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).
+When 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).
+
 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .