Re: more bugs in branch-2-0/HEAD

[Gary V. Vaughan]

Summary:

I move to strike the lt_dlcaller_register api change from the list of
release blockers.  From the list of known bugs altogether in fact.  Read
on to find out why...

Gary V. Vaughan wrote:
> Peter O'Gorman wrote:
> 
>> Gary V. Vaughan wrote:
>>
>> | I would deprecate the old api:
>> |
>> |     lt_dlcaller_id lt_dlcaller_register (void);
>> |
>> | And make the new call:
>> |
>> |     lt_dlcaller_id lt_dlcaller_register_iface (const char *...
>> |
>> | This should be a simple matter of tweaking the docs, renaming the
>> | current /lt_dlcaller_register/ to \&_iface, and then factoring out
>> | the guts of the new \&_iface into a backwards compatible
>> | lt_dlcaller_register.
>> |
>> | I think the docs should relegate mention of the old style
>> | lt_dlcaller_register to a footnote that says it is still present
>> | but deprecated.
>>
>> Fine with me... are you volunteering to do this? :)
> 
> 
> It's very mechanical.
> 
> If no-one else has gotten to it by the time I finish the pernickerty
> api twiddling and documentation for LT_WITH_LTDL and LTDL_INIT,
> then I'll look at it.  Probably a few days from now.

Well, I lied.  On all counts. :-D  I broke compatibility on purpose,
but it was such a long time ago that I had forgotten why until I just
tried to fix it.

It would be a bad thing to fix this because libltdl now puts modules
in the global handle list, and using the lt_dlcaller_register (void)
call shows that the calling application is not aware of this.  If we
change the footprint back, such applications can be linked against a
new libltdl without being changed to take account of the modules
loaded by other libraries (i.e libltdl, after the release other libs
may too start loading modules).  If such a client naively links with
new libltdl, it will start trying to fiddle with modules that belong
to other libraries.  Figuring out what the new arguments are for after
a compilation error will lead the developer to understanding this and
hopefully using the new libltdl correctly.

The interface numbers of libltdl have been bumped accordingly to avoid
any possible problems with binaries linked against a 1.5.x era ltdl,
so that is okay too.  And is again deliberate to prevent applications
trying to load libraries that each use incompatible module loaders.

If anything, as part of the move to a new interface, we should change
all of the functions that iterate over all loaded modules too, so that
developers don't accidentally start poking around with modules that
were loaded by another library.

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