Update.
authorUlrich Drepper <drepper@redhat.com>
Mon, 8 Mar 1999 11:57:06 +0000 (11:57 +0000)
committerUlrich Drepper <drepper@redhat.com>
Mon, 8 Mar 1999 11:57:06 +0000 (11:57 +0000)
1999-03-02  Mark Kettenis  <kettenis@gnu.org>

* Makerules (LD_FLAGS-c.so): Add -u __register_frame to force the
backward compatibility EH functions to be linked when using
gcc-2.8.1.  Patch by Zack Weinberg <zack@rabi.columbia.edu>.

ChangeLog
FAQ
FAQ.in
Makerules

index 6e769be..9a8ea2d 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+1999-03-02  Mark Kettenis  <kettenis@gnu.org>
+
+       * Makerules (LD_FLAGS-c.so): Add -u __register_frame to force the
+       backward compatibility EH functions to be linked when using
+       gcc-2.8.1.  Patch by Zack Weinberg <zack@rabi.columbia.edu>.
+
 1999-03-08  Andreas Schwab  <schwab@issan.cs.uni-dortmund.de>
 
        * sysdeps/unix/sysv/linux/ttyname.c (ttyname): Undo last change.
diff --git a/FAQ b/FAQ
index 3de7dfe..5fe4be4 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -143,6 +143,8 @@ please let me know.
        execute any binaries.  What went wrong?
 3.19.  bonnie reports that char i/o with glibc 2 is much slower than with
        libc5.  What can be done?
+3.20.  Programs compiled with glibc 2.1 can't read db files made with glibc
+       2.0.  What has changed that programs like rpm break?
 
 4. Miscellaneous
 
@@ -1497,6 +1499,22 @@ suffix `_unlocked', for details check <stdio.h>.  Using `putc_unlocked' etc.
 instead of `putc' should give nearly the same speed with bonnie (bonnie is a
 benchmark program for measuring disk access).
 
+
+3.20.  Programs compiled with glibc 2.1 can't read db files made with glibc
+       2.0.  What has changed that programs like rpm break?
+
+{AJ} The GNU C library 2.1 uses db2 instead of db1 which was used in version
+2.0.  The internal formats of the actual db files are different.  To convert
+the db files from db1 format to db2 format, you can use the programs
+`db_dump185' and `db_load'.  Alternativly programs can be linked with db1
+using `-ldb1' instead of linking with db2 which uses `-ldb'.  Linking with
+db1 might be preferable if older programs need to access the db file.
+
+db2 supports the old db1 programming interface and also a new programming
+interface.  For compilation with the old API, <db_185.h> has to be included
+(and not <db.h>) and you can link with either `-ldb1' or `-ldb' for either
+of the db formats.
+
 \f
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
 
diff --git a/FAQ.in b/FAQ.in
index 91acca2..9f92170 100644 (file)
--- a/FAQ.in
+++ b/FAQ.in
@@ -1287,6 +1287,21 @@ suffix `_unlocked', for details check <stdio.h>.  Using `putc_unlocked' etc.
 instead of `putc' should give nearly the same speed with bonnie (bonnie is a
 benchmark program for measuring disk access).
 
+??     Programs compiled with glibc 2.1 can't read db files made with glibc
+       2.0.  What has changed that programs like rpm break?
+
+{AJ} The GNU C library 2.1 uses db2 instead of db1 which was used in version
+2.0.  The internal formats of the actual db files are different.  To convert
+the db files from db1 format to db2 format, you can use the programs
+`db_dump185' and `db_load'.  Alternativly programs can be linked with db1
+using `-ldb1' instead of linking with db2 which uses `-ldb'.  Linking with
+db1 might be preferable if older programs need to access the db file.
+
+db2 supports the old db1 programming interface and also a new programming
+interface.  For compilation with the old API, <db_185.h> has to be included
+(and not <db.h>) and you can link with either `-ldb1' or `-ldb' for either
+of the db formats.
+
 
 ? Miscellaneous
 
index cf0a6a5..984a8ad 100644 (file)
--- a/Makerules
+++ b/Makerules
@@ -405,6 +405,8 @@ LDFLAGS-c.so = -nostdlib -nostartfiles
 LDLIBS-c.so += $(gnulib)
 # Give libc.so an entry point and make it directly runnable itself.
 LDFLAGS-c.so += -e __libc_main
+# Force the backward compatibility EH functions to be linked.
+LDFLAGS-c.so += -u __register_frame
 # Pre-link the objects of libc_pic.a so that we can locally resolve
 # COMMON symbols before we link against ld.so.  This is because ld.so
 # contains some of libc_pic.a already, which will prevent the COMMONs