Kenny Simpson wrote: > Not sure if this is the best forum for this question, but... > > On Linux/x86 (RHEL5), I produce a versioned ELF C++ library using > SONAME. I have a user that loads in multiple versions of this > library into the same process much in the way a java process uses a > classloader to manage multiple concurrent versions of jars. > > (don't ask why they insist on doing this- they like Frankenstein > applications) > > This seems likely to cause issues with symbol lookup resolving > against library versions loaded earlier (violations of the ODR, > etc..) > > Unfortunately, the library has no real stable API, nor a defined > namespace for all 'exported' symbols. > > Is there a (simple?) way this can be made to work, or do I need to > tell my user to stop doing that? > > I've tried a few quick experiments with -Wl,--default-symver and > this seems promising, but I'm wondering if there is some other, > possibly c++-guts-related, subtle issue I could miss. > > The other thought was to try to retro-fit a versioned namespace > around the library - but this would be very very painful. > > Any input much appreciated. This is going to be painful. In gcj we solve the problem by implementing our own symbol resolution mechanism and using that rather than ld.so. This works, but is far more heavyweight than anything you have in mind. You can use -Bsymbolic-functions or -Bsymbolic but this stuff is very hairy and will probably lead to hard-to-find bugs. Andrew.
