[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 17:03:57 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Gary V. Vaughan skrev 2011-10-25 14:17:
> Hi Peter,
> On 25 Oct 2011, at 18:12, Peter Rosin wrote:
>> Gary V. Vaughan skrev 2011-10-25 12:51:
>>> 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?
>>> Here's what I'm proposing to do for the upcoming libtool alpha release:
>>>  1. Remove all traces of LT_SCOPE, and just use plain 'extern' in
>>>     public header files.
>>>  2. Remove the code for setting and passing LTDL_DLL_IMPORT.
>>>  3. I can then safely eliminate $prefix/include/libltdl/lt_system.h,
>>>     and simplify the public headers for libltdl considerably.
>>> Do you forsee any issues on Windows with my doing that?
>>> I'm almost certain that modern gcc and hence cygwin and variants will
>>> continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends,
>>> but I have no clue whether vendor compilers that currently work (or at
>>> least are supported and supposed to work) with the current release are
>>> relying on LT_SCOPE magic from libltdl.
>> I'm fairly certain that removing LT_SCOPE wholesale would break Libtool
>> in one way or the other for Microsoft Visual C. Please don't do it
>> without checking the effects on the testsuite first.
>> I can check if you provide a patch.
> Awesome, thanks.
> I put up a set of tarballs from a make distcheck of the 2.4.2 release with
> a minimal patch that simply forces LT_SCOPE to always be extern.  You can get
> them here:
> Obviously they passed a full distcheck on my machine, and I'm quietly hoping
> there'll be no regressions on your machines compared to the raw 2.4.2
> release I put out recently.  If so, that covers point 1 of my original post,
> and I can seriously tidy up the installed files from libltdl and start
> thinking more about point 2 as well.
> Let me know how you get on.

I configures both the way I usually configure libtool for msvc, i.e.

../configure autobuild_mode=msvc CC="/c/cygwin/home/peda/automake/lib/compile 
cl" CFLAGS="-MD -Zi -EHsc" CXX="/c/cygwin/home/peda/automake/lib/compile cl" 
CXXFLAGS="-MD -Zi -EHsc" LD=link NM="dumpbin -symbols" STRIP=: 
AR="/c/cygwin/home/peda/automake/lib/ar-lib lib" RANLIB=: F77=no FC=no GCJ=no

The testsuite result seems identical, with two good old failures:

old testsuite:
FAIL: tests/demo-deplibs.test

new testsuite:
107: test --with-pic                                 FAILED (

But see my response to Bob's mail for further fodder for thought...

I should also state that this is the first time I tried the Libtool testsuite
with the real Visual Studio 2010, and that I don't have any older version
installed on my newish machine (yet). So, conclusions are a bit unreliable...


reply via email to

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