Re: Libtool 2.2 ABI issue

[Ralf Wildenhues]

Hi Yoann,

* Yoann Vandoorselaere wrote on Tue, Nov 04, 2008 at 04:16:47PM CET:
> We are experiencing an issue following the libtool/libltdl 2.2 release
> due to the way we use the system in Prelude.
> 
> The Prelude library (libprelude), provide a plugin API using
> libtool/libltdl, and try to hide most of the details to the application
> implementing plugin support through libprelude (for one, application
> don't have to use libltdl directly).
> 
> In order to support dlpreopening, libprelude used to provide the
> following support code in prelude-plugin.h:

> extern const void *lt_preloaded_symbols[];
> 
> #define PRELUDE_PLUGIN_SET_PRELOADED_SYMBOLS()                     \
>         prelude_plugin_set_preloaded_symbols(lt_preloaded_symbols)

Can you not include <ltdl.h> and use LTDL_SET_PRELOADED_SYMBOLS
for your definition of PRELUDE_PLUGIN_SET_PRELOADED_SYMBOLS?

AFAICS then that would solve your "second problem", too, no?

> This used to work fines with libtool 1.5, but we are now facing two
> problem:
> 
> There is an ABI compatibility issue when libprelude is compiled with
> libtool/libltdl 2.2 but programs using it generated the dlpreopening
> table through libtool 1.5.

Yep.  Two issues, actually: libltdl changed incompatibly, *and* the
libtool version must be on the same side of the 2.0 divide as the
libltdl version, too.  :-/

Only upside is that the change was done for allowing to dlpreopen from
libraries, which couldn't be done safely before.

> I found a partial solution to this problem by rewriting the table if its
> first symbol is NULL or doesn't contain @address@hidden However, I find this
> solution less than ideal, so any comment on this solution will be
> welcome. 

Well, I'd like to believe that the symlist data structure and contents
is an internal detail, that you shouldn't (need to) know about.

I'll look at your proposed function tomorrow.

Cheers,
Ralf