bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libtool 2.2 ABI issue


From: Ralf Wildenhues
Subject: Re: Libtool 2.2 ABI issue
Date: Tue, 11 Nov 2008 21:04:43 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Yoann,

sorry for the delay.

* Yoann Vandoorselaere wrote on Tue, Nov 04, 2008 at 04:16:47PM CET:
> 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. 

Looks ok, only nits:

> void prelude_plugin_set_preloaded_symbols(void *symlist)
> {
>         size_t len;
>         lt_dlsymlist *s = symlist;
>         static lt_dlsymlist rpl_sym[65535] = {
>                 { "@PROGNAME@", NULL },
>                 { NULL, NULL         }
>         };
> 
>         if ( s[0].name == NULL || strcmp(s[0].name, "@PROGNAME@") != 0 )
> {
>                 for ( len = 0; s[len].name != NULL; len++ );
> 
>                 if ( len + 1 >= sizeof(rpl_sym) / sizeof(*rpl_sym) ) {

>                         prelude_log(PRELUDE_LOG_CRIT, "replacement symlist is 
> not large enough (%lu entry).\n", len);
>                         len = (sizeof(rpl_sym) / sizeof(*rpl_sym)) - 1;

This is an off-by-one: rpl_sym only has space for
  (sizeof(rpl_sym) / sizeof(*rpl_sym)) - 2
entries.

>                 }
> 
>                 /*
>                  * Copy as much symbols as possible, and set the last entry 
> to NULL.

( s/much/many/  ;-)

>                  */
>                 memcpy(&rpl_sym[1], s, len * sizeof(*rpl_sym));
>                 rpl_sym[len].name = NULL;

Here, you overwrite the last entry's ".name" record.

>                 s = rpl_sym;
>         }
> 
>         lt_dlpreload_default(s);
> }

> The second problem is due to libtool 2.2 renaming the symbol table from
> lt_preloaded_symbols to lt__PROGRAM__LTX_preloaded_symbols.
> 
> A fixe for this issue would be to be able to determine the libtool
> version being used at compile time.

I haven't fully understood your setting, thus your needs.  Let me try:

You have a package you control (prelude) plus a number of packages that
you don't control, but that use your headers/build plugins with prelude.

You control the libtool and libltdl versions with which prelude is built
and installed (both from the Libtool 2.2.x tree), but you do not control
the libtool version with which your "client packages" are built.  These
client packages typically do not have anything to do with libltdl.

You do not need to be able to build prelude itself with Libtool 1.5.x
any more (neither libtool nor libltdl).

Right so far?

I think you could write an Autoconf macro for your users' packages to
incorporate into their configure scripts.  In it, you could AC_DEFINE
a couple of variables based upon whether they use Libtool 1.5.x or
2.2.x.

In order to require a certain Libtool version, the macro LT_PREREQ
has been added to 2.2.x, and LT_PACKAGE_VERSION contains some version
string.  However, in your case I'd probably do something like
  m4_ifdef([LT_INIT],
           [deal with 2.2.x],
           [deal with 1.5.x or older])

Hope that helps.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]