Re: libc/1508: symbol conflict due to nss_db.so usage of /lib/libdb.so.3

[Michael Marxmeier <mike at msede dot com>]

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/