Crash when using dlmopen

[Mike Hearn <mike at plan99 dot net>]

Hi,

I have a program that links against libSDL, which dlopens the aRts sound
server library (libartsc.so.0) which in turns dlopens various other
libraries.

I'm experimenting with using an LD_PRELOAD module to force the first
dlopen of libartsc.so.0 into a new namespace using dlmopen instead of
regular dlopen. That's because otherwise there are C++ symbol conflicts
between libstdc++.so.5 which is what the game uses and libstdc++.so.6
which is what my copy of arts uses. The symbol versioning is not enough to
stop this (there is a bug in GCC bugzilla about it).

The first dlmopen seems to work OK judging by the LD_DEBUG traces, but
when libartsc (now in namespace 1) tries to dlopen another library it
crashes somewhere inside the dynamic linker. 

I tried to get a backtrace of this crash, the best I could get was one
that indicated the crash happened inside dlopen_doit, which is quite early
on and unlikely to be the real source of the bug. GDB was totally useless,
it seems completely broken on FC4 - even with the debuginfo packages
installed it does not give a real backtrace of most apps I try it with. I
had to use catchsegv and valgrind instead.

Does anybody have some ideas on why this might crash? Am I mis-using the
API?

Also, I tried using RTLD_DEEPBIND as I thought that would be similar to
grouped fixup as implemented on Solaris. But it seems that this option
does not do what I thought it did - symbols are still bound back to the
original binary even though the executable is not "deeper" in the tree
than that library.

Can anybody explain why RTLD_DEEPBIND is not doing as I expected?

thanks -mike