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: > > http://vaughan.pe/libtool/libtool-2.4.2-no-lt-scope.tar.gz > http://vaughan.pe/libtool/libtool-2.4.2-no-lt-scope.tar.xz > > 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 (with-pic.at:40) 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... Cheers, Peter _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
