Re: rename troublesome ltdl apis [libtool--devo--1.0--patch-275]

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:52:06AM CEST:
> Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:05:48PM CEST:
> >>    * libltdl/ltdl.c (lt_dlcaller_register, lt_dlcaller_set_data)
> >>    (lt_dlcaller_get_data): Renamed to avoid problems with module
> >>    visibilty when linked with programs written for the old API.
> >>    compatible zero argument version, adding a deprecation warning.
> >>    (lt_dlinterface_register, lt_dlinterface_set_data)
> >>    (lt_dlinterface_get_data): New names.
> >>    * Makefile.am (VERSION_INFO): Bumped.
> >>    * doc/libtool.texi (User defined module data): Updated.
> > 
> > I don't understand why now you start to rename _all_ of that stuff, and
> > not only the troubling lt_dlcaller_register.
> 
> For exactly the same reasons as with lt_dlcaller_register.  It all
> follows on quite logically -
> 
>   i) lt_dlcaller_id was declared as an unsigned int in old ltdl.h,
>      but lt_dlinterface_register no longer returns an unsigned int,
>      but an opaque void*.

OMG.  I overlooked that.  What a mess.  :(

>      To prevent difficult bugs with platforms
>      that have different sized void* and unsigned especially, but
>      also regular users to some extent we need to rename lt_caller_id
>      to lt_dlinterface_id.

When it comes to interface stability, libltdl is a particularly well
suited counter-example.  :(

>  ii) Now, lt_dlcaller_{g,s}et_data each take an argument of a different
>      type than before (void * vs unsigned) and rather than relying on
>      just the compiler's type checking by your argument for renaming
>      lt_dlcaller_register, these functions too need renaming.

Oh brother.

Let's approach this from a different side: how many packages actually
make use of these functions?  I would be a lot less uncomfortable with
these changes if I knew that nobody besides m4 actually used any of
this.

> > This places an undue
> > burden on innocent users that never deal with more than one module
> > loader.  Those would otherwise be fine with just adapting their call of
> > lt_dlcaller_register.
> 
> There are no such users with libtool-2.0, as libltdl itself has modules
> in the handles list which (like all modules) should be protected from
> other clients (hence my patch-277).  In order to do that, lt_dlcaller_id
> needs to be richer than an unsigned, and the rest follows as explained
> above.  Assuming popular libraries take advantage of 2.0 libltdl module
> loading, inevitably some ltdl module loading libraries can have no clue
> as to whether their client application, or other libraries that client
> uses will be adding modules to the internal ltdl handle list, and we
> need to make it as robust as possible for each client to not worry about
> modules loaded by the others... lt_dlinterface_id was the mechanism I
> invented for this purpose, but failed to follow through to the rest of
> the libltdl API until now.

Hmm.  But the whole module-loading-libraries is still not fully
functional without help from the program because of the
LTDL_SET_PRELOADED_SYMBOLS issue?  Is that correct?  Is that the only
remaining structural problem?  (I have another usage report about this
with open questions coming up, on the libtool list.)

> > There is no need to keep users from shooting themselves in the foot, if
> > they ignore documentation.
> >
> > Am I missing something again?
> 
> Only the same arguments we both put forth for changing the name of
> lt_dlcaller_register -- forced to change function footprint to avoid
> problems with other clients' modules, which in turn suggests a good
> reason to rename said functions to force a hard compilation failure if
> the user doesn't upgrade the caller's semantics to match the new APIs.

Yes, I think this part I can follow now.

Do any packages use these features extensively?  IOW, can m4 serve at
least as a good testbed for your last three patches?  Because I will
not give my ACK unless it does not regress on at least mingw, cygwin,
a standard unix and a static-only platform (AIX would be good, too),
where regressing is measured in "these code paths are actually used at
some place".  And I also still want to read the patches closely..

Cheers,
Ralf