[Top][All Lists]

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

Re: Obsoleting LT_SCOPE

From: Peter Rosin
Subject: Re: Obsoleting LT_SCOPE
Date: Tue, 25 Oct 2011 16:34:04 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Bob Friesenhahn skrev 2011-10-25 16:00:
> On Tue, 25 Oct 2011, Gary V. Vaughan wrote:
>> Hi Chuck,
>> 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?

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

Do we not have any tests where the dynamic version of libltdl is used?
Because I'm surprised to not have seen any new testsuite fails by now...

Also, by removing LT_SCOPE you will cause regressions for gcc users in
projects that declare other symbols dllexport, because doing that for any
one symbol will disable the autoexport of other symbols (e.g. if you build
a shared lib that contains a libltdl convenience lib). I think.
I.e., the current behavior has potentially forced others to declare symbols
dllexport, and now those dllexports prevent Libtool from removing its
own dllexports without introducing a flag day. I think.


reply via email to

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