Re: Obsoleting LT_SCOPE

[Peter Rosin]

Gary V. Vaughan skrev 2011-10-25 18:07:
> I should also add:
> 
> On 25 Oct 2011, at 21:34, Peter Rosin wrote:
>> Bob Friesenhahn skrev 2011-10-25 16:00:
>>> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
>>>> I note that no other GNU projects that I'm aware of jump through all the
>>>> __declspec hoops that the libltdl API tries to provide through LT_SCOPE.
>>>> Is any of this stuff still required on any non-museum Windows compiler
>>>> that would break if I removed it?
>>>
>>> Isn't this functionality required for every Windows compiler other than GCC?
> 
> That certainly used to be the case, and at the time we introduced it, even
> gcc on windows couldn't build a libltdl DLL that worked correctly without it.
> 
> But, it seems to me that we are the only project (at least that I'm able to
> find easily) that goes to this trouble.  Not that I want to break our support
> for additional platforms at all, but I wonder whether we might be clinging to
> the past a little with LT_SCOPE?
> 
>> (testsuites for 2.4.2-no-lt-scope, at 113 in the new testsuite, and 2.4.2,
>> at 106, currently running. No visible difference so far, but the massive
>> Link option thorough search test is still todo for both. Stay tuned)
>>
>> IIRC, for Microsoft Visual C, the minimal cruft in this area is to let
>> libtool dig out the exports when building DLLs and export them and then to
>> always declare symbols dllimport when using the library, even if you link
>> with a static version of the library. But IIRC it will not work to link
>> with a DLL unless you have declared the symbols dllimport so I can't see
>> how it's going to work with only an extern.
> 
> My recollection is that it was only necessary for data exports, but our
> entire API is defined in terms of function exports now... and the comment
> in lt_system.h says:
> 
> /* DLL building support on win32 hosts;  mostly to workaround their
>    ridiculous implementation of data symbol exporting. */
> 
> Still crossing my fingers that there's room for us to simplify and remove
> some cruft.

Ahhh, data exports.  That's it.  Now I have actually looked up what I'm
doing in a library project that has data exports.

Export variables: extern
Export functions: /* nothing, but extern would also work, famous last words */
Import variables: extern __declspec(dllimport)
Import functions: extern

And this works (with some warnings) even if linking against a static version
of the library in question (which is nice since you are therefore not
required to know at compile time if you are going to link against the
shared or the static lib).

So one question is if libltdl really is free from data exports. I think not,
what about lt_preloaded_symbols?

Another question is what to do about cccl users.  Libtool is not capable
of auto-exporting symbols in the cccl case, Libtool only does that in case
MSVC is used w/o cccl.  I bet there are users out there still using cccl,
but I could not get in contact with them when I was working on Libtool.
I have no desire to dig into the cccl code in Libtool. One reason is that
I don't know what version of cccl I should use, everybody and his brother
seem to have added hacks of their own with no clear upstream. Another is
that it would take too much of my precious spare time with little reward.

Cheers,
Peter