libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obsoleting LT_SCOPE


From: Gary V. Vaughan
Subject: Re: Obsoleting LT_SCOPE
Date: Tue, 25 Oct 2011 23:07:25 +0700

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.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]