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 ())_. [EMAIL PROTECTED],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
