Re: Obsoleting LT_SCOPE

[Gary V. Vaughan]

Hi Peter, Bob, Chuck,

Thanks all for the feedback.

And Peter especially for running the torturous testsuites on Windows :)

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

I have to bow to your superior knowledge of Windows, which I haven't used
for development since Windows NT 4, but it feels weird that Libltdl really
does twist itself into a pretzel for Windows... and yet all the other GNU
projects I've looked at do no such thing (possibly because I haven't yet
found another one that can be compiled with MSVC).

Either way, it would be great to get some empirical evidence that LT_SCOPE
is still necessary, or better yet that MS linkers can cope with POSIX style
header declarations these days so we don't need to bend over quite so much!

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

What do you have in mind?  The mdemo tests should be linking with libltdl.dll
at least, no?  If we're missing some coverage, can you help me to construct
a test that works with LT_SCOPE circa 2.4.2, and chokes with unconditional
#define LT_SCOPE extern?

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

Interesting, I hadn't thought of that.  If it turns out that LT_SCOPE is
only necessary for backwards compatibility, and throwing out those convolutions
would otherwise be possible, I think we can ease out of it slowly... say, a
year more with the current behaviour the default with a warning it will go away
soon, and after that recommend continuing to use and old release after that when
we move to the cleaner LT_SCOPE free paradigm - assuming it is even possible 
that
is.

And of course, if LT_SCOPE is part of the required support for MSVC compilers,
then I wouldn't dream of breaking it (deliberately).

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