Embedding libltdl into middleware

[Jeff Squyres]

Greetings all.  As I've posted on this list a few times before, I am  
one of the developers of the Open MPI project (www.open-mpi.org).  Our  
software is heavily based on the concept of plugins; we use libltdl  
for opening plugins and finding symbols.

One of the libraries in Open MPI (libopen-pal.la) embeds libltdl by  
adding libltdlc.la to libopen_pal_la_LIBADD.  We chose to embed  
because of many of the reasons cited in the v2.2.6a Libtool docs  
section 11.6 ("How to distribute libltdl with your package").  Note  
that user applications link against libopen-pal; so user applications  
will have visibility of the embedded libltdlc.

A user has recently complained (http://www.open-mpi.org/community/lists/users/2009/01/7793.php 
) that if they link an MPI application against Open MPI v1.3's  
middleware libraries and explicitly -lldtl on their link command line,  
Bad Things happen.  This is because the Open MPI-embedded libltldl is  
2.2.6a and the OS-installed version is 1.5.something.  This effect is  
described multiple times in section 11.6 of the Libtool docs, so I  
assume the problem is well-understood and I won't go into further  
detail.

Would the Libtool project consider adding a configure-time option to  
prefix all public libltdlc symbols with a specified string?  This  
would enable an embedded libltdlc to never conflict with an external  
libltdl, even if both were linked together into the same executable.   
For example:

  LT_CONVENIENCE_PREFIX([openmpi_lt])

(or something similar) could result in symbols like  
openmpi_lt_dlopen() and openmpi_lt_dlsym() in libltdlc.  Therefore:

  gcc my_program.c ... -lopenmpi-with-embedded-libltdlc -lltdl -o  
my_program

would still work fine because the two different versions of libltdl  
would have entirely different namespaces in my_program and not clash,  
both at link time and at run time.

FWIW, the PLPA project (http://www.open-mpi.org/projects/plpa/) offers  
a configure option for prefixing all public symbols for exactly this  
reason.  The same technique could be used with libltdl.

Would such a thing be possible?

--
Jeff Squyres
Cisco Systems