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

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf,

Thanks for reviewing.

> * 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:
>>>
>>>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.  :(

Indeed :-(  Extreme programming methodologies only work in a vacuum.

>> 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.

For this particular patch, only m4 that I am aware of, but it's been
around long enough that we should take care over it in case it has been
quietly but widely adopted.

>>>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?

Argh.  I'd forgotten about that :-(

> Is that correct?

Yes, certainly it is correct for preloaded modules.  However, I don't
think we need to worry about fixing this for 2.0 -- although it might
be good to document that if libraries use the new library dlloading
with preopened libraries, they will be relying on the application to
invoke LTDL_SET_PRELOADED_SYMBOLS :-(

> Is that the only remaining structural problem?

I can't think of anything else right now.

>  (I have another usage report about this
> with open questions coming up, on the libtool list.)

Okay.

>>>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?

Sure.  You want me to post the matching patches for m4 too?

> 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".

Good call.  I only have access to Gentoo-2005.0, Mac OS 10.4.2. :-(
I can preroll test tarballs of libtool and m4 with the patches applied
if that helps...

> And I also still want to read the patches closely..

Okay, I'll wait for your comments before I make m4 patches.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature