libc/1508: symbol conflict due to nss_db.so usage of /lib/libdb.so.3
Michael Marxmeier
mike@msede.com
Tue Jan 4 16:54:00 GMT 2000
Hello Mark et al.
Already tried MALLOCK_CHECK_ before reporting the problem initially.
No difference.
Mark Kettenis wrote:
> We probably shouldn't export __db_jump from the libdb.so that comes
> with glibc. It is an internal symbol. Unfortunately we need to
> export it because two of the maintenance programs that come with the
> db library need __db_jump. This can be fixed though.
Yep. I re-built glibc-2.1.2 with your proposed modifications. Works.
So it's most likely related to __db_jump.
While db_jump could be fixed (eg. changing the name) don't we need
to worry about the other internal symbols which are visible from
the application?
# __bam_init_print; __bam_pgin; __bam_pgout;
# __db_dispatch;__db_dump; __db_err; __db_init_print;__db_jump;
# __db_omode;__db_prdbt;
# __ham_init_print; __ham_pgin; __ham_pgout;
# __lock_dump_region;
# __log_init_print;
# __memp_dump_region;
# __txn_init_print;
The same issue may affect them as well?
# nm /lib/libdb.so.3|fgrep __bam_pgin
000041f0 T __bam_pgin
# nm ../../../../bin/msg/lib/libdb26.so| fgrep __bam_pgin
00007890 T __bam_pgin
Sure it's text. But does dld.so allow the same global symbol
multiple times?
Thanks for your help
Michael
--
Michael Marxmeier Marxmeier Software AG
E-Mail: mike@msede.com Besenbruchstrasse 9
Phone : +49 202 2431440 42285 Wuppertal, Germany
Fax : +49 202 2431420 http://www.msede.com/
More information about the Libc-alpha
mailing list