Re: Obsoleting LT_SCOPE
Peter Rosin skrev 2011-10-25 21:11: *snip* However, and more importantly, I also found this in the build logs of both stock 2.4.2 and 2.4.2-no-lt-scope: cl -link -EXPORT:lt__alloc_die,DATA ... -link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA ... So, there are indeed data exports in libltdl. Anyone trying to make use of those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So, we need a test case exercising one or the other of those exports. Or both. I tried briefly to write tests for those two and quickly ran into problems coming up with any meaningful test... It appears that lt__alloc_die is only ever used by internal functions of libltdl, so it should not need to be an export (LT_SCOPE). A plain extern should be enough for that symbol, always. The symbol is also not visible in any public header, so any (ab)users deserve to lose big time. For the other exported data symbol (lt_ltdl_LTX_preloaded_symbols), it appears that it is also an internal artifact that is not really a part of the API and also not really meant to be touched by anything external to the finished library. The symbol is also not exported when building with gcc (although named lt_libltdl_LTX_preloaded_symbols there), as it is a plain extern (and since there are other symbols explicitly declared dllexport, this one is not exported, so switching over to plain extern everywhere and relying on auto-export would expose this symbol for gcc builds as well). It is visible when using MSVC since Libtool exports all non-static symbols for MSVC (unless you use one of the -export-symbols* options). I.e., there are no data symbols to import, just data symbols leaking out. In other words, no need to dllimport anything since MSVC auto-imports functions. So, to sum up my current understanding of the situation: * For gcc, there would be a flag day due to the troubles described by me [1] and by Roumen [2]. I think we describe the same issue. I'm not sure it is possible to give a warning in advance without adding an option to activate the new non-LT_SCOPE-style extern declaration and warn if that option is not present (or force a backwards-compatibility option to activate the old behavior, but when to warn in that case?) * For MSVC with cccl, it would probably break horribly. But Libtool with cccl is already severely broken and not even close to the level of support as without cccl, at least according to the testsuite. BUT, that is only with the versions of cccl that I have tried, there might be some version of cccl that works beautifully and that would break horribly. Search me... * For MSVC without cccl, it is perfectly fine to drop LT_SCOPE. Given that the analysis about the two data exports holds of course. * We have not discussed other compilers. Intel C Compiler anyone? Portland Group? Watcom? Borland? But I suppose any current Libtool support for those are sketchy at best and any future work could always piggyback on the Libtool auto-export code currently active for MSVC without cccl. MSVC with cccl could also add Libtool style auto-export I suppose. But someone has to do the legwork. * OS/2. That's a dead end, right? The gcc flag-day thing is the big issue with MSVC with cccl a distant second if you ask me. Cheers, Peter [1] http://lists.gnu.org/archive/html/libtool/2011-10/msg00030.html [2] http://lists.gnu.org/archive/html/libtool/2011-10/msg00037.html ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
Sorry to reply to self. Peter Rosin skrev 2011-10-31 12:54: Peter Rosin skrev 2011-10-25 21:11: *snip* However, and more importantly, I also found this in the build logs of both stock 2.4.2 and 2.4.2-no-lt-scope: cl -link -EXPORT:lt__alloc_die,DATA ... -link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA ... So, there are indeed data exports in libltdl. Anyone trying to make use of those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So, we need a test case exercising one or the other of those exports. Or both. I tried briefly to write tests for those two and quickly ran into problems coming up with any meaningful test... It appears that lt__alloc_die is only ever used by internal functions of libltdl, so it should not need to be an export (LT_SCOPE). A plain extern should be enough for that symbol, always. The symbol is also not visible in any public header, so any (ab)users deserve to lose big time. For the other exported data symbol (lt_ltdl_LTX_preloaded_symbols), it appears that it is also an internal artifact that is not really a part of the API and also not really meant to be touched by anything external to the finished library. The symbol is also not exported when building with gcc (although named lt_libltdl_LTX_preloaded_symbols there), as it is a plain extern (and since there are other symbols explicitly declared dllexport, this one is not exported, so switching over to plain extern everywhere and relying on auto-export would expose this symbol for gcc builds as well). It is visible when using MSVC since Libtool exports all non-static symbols for MSVC (unless you use one of the -export-symbols* options). I.e., there are no data symbols to import, just data symbols leaking out. In other words, no need to dllimport anything since MSVC auto-imports functions. So, to sum up my current understanding of the situation: * For gcc, there would be a flag day due to the troubles described by me [1] and by Roumen [2]. I think we describe the same issue. I'm not sure it is possible to give a warning in advance without adding an option to activate the new non-LT_SCOPE-style extern declaration and warn if that option is not present (or force a backwards-compatibility option to activate the old behavior, but when to warn in that case?) * For MSVC with cccl, it would probably break horribly. But Libtool with cccl is already severely broken and not even close to the level of support as without cccl, at least according to the testsuite. BUT, that is only with the versions of cccl that I have tried, there might be some version of cccl that works beautifully and that would break horribly. Search me... * For MSVC without cccl, it is perfectly fine to drop LT_SCOPE. Given that the analysis about the two data exports holds of course. * We have not discussed other compilers. Intel C Compiler anyone? Portland Group? Watcom? Borland? But I suppose any current Libtool support for those are sketchy at best and any future work could always piggyback on the Libtool auto-export code currently active for MSVC without cccl. Hmm, but what if the others don't do auto-import? Didn't think of that... MSVC with cccl could also add Libtool style auto-export I suppose. But someone has to do the legwork. * OS/2. That's a dead end, right? The gcc flag-day thing is the big issue with MSVC with cccl a distant second if you ask me. Cheers, Peter [1] http://lists.gnu.org/archive/html/libtool/2011-10/msg00030.html [2] http://lists.gnu.org/archive/html/libtool/2011-10/msg00037.html ___ https://lists.gnu.org/mailman/listinfo/libtool
Obsoleting LT_SCOPE
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? 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. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
Gary V. Vaughan skrev 2011-10-25 12:51: 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? 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. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
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. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
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? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
On 10/25/2011 6:51 AM, Gary V. Vaughan wrote: Do you forsee any issues on Windows with my doing that? Yes. 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. Modern gcc will be fine on cygwin, mingw, and mingw64. What will break completely is any version of Visual Studio, including 2010 -- which I'm fairly sure is not a museum piece. It would be a shame to obviate all of Peter's work getting libtool itself to work with MSVC, and then to break that platform's libltdl.dll. But I'll let Peter take point on this one. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
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. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
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
Re: Obsoleting LT_SCOPE
On 10/25/2011 11:03 AM, Peter Rosin wrote: Gary V. Vaughan skrev 2011-10-25 14:17: 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: Be sure and check the exports from libltdl*.dll from before and after... -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
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) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
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) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
Gary V. Vaughan skrev 2011-10-25 18:07: 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. Ahhh, data exports. That's it. Now I have actually looked up what I'm doing in a library project that has data exports. Export variables: extern Export functions: /* nothing, but extern would also work, famous last words */ Import variables: extern __declspec(dllimport) Import functions: extern And this works (with some warnings) even if linking against a static version of the library in question (which is nice since you are therefore not required to know at compile time if you are going to link against the shared or the static lib). So one question is if libltdl really is free from data exports. I think not, what about lt_preloaded_symbols? Another question is what to do about cccl users. Libtool is not capable of auto-exporting symbols in the cccl case, Libtool only does that in case MSVC is used w/o cccl. I bet there are users out there still using cccl, but I could not get in contact with them when I was working on Libtool. I have no desire to dig into the cccl code in Libtool. One reason is that I don't know what version of cccl I should use, everybody and his brother seem to have added hacks of their own with no clear upstream. Another is that it would take too much of my precious spare time with little reward. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
Charles Wilson skrev 2011-10-25 17:34: On 10/25/2011 11:03 AM, Peter Rosin wrote: Gary V. Vaughan skrev 2011-10-25 14:17: 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: Be sure and check the exports from libltdl*.dll from before and after... Right, good suggestion: $ diff -u libtool-2.4.2/msvc/libltdl/.libs/ltdl.dll.lib.nm libtool-2.4.2-no-lt-scope/msvc/libltdl/.libs/ltdl.dll.lib.nm --- libtool-2.4.2/msvc/libltdl/.libs/ltdl.dll.lib.nm2011-10-25 20:44:58 +0200 +++ libtool-2.4.2-no-lt-scope/msvc/libltdl/.libs/ltdl.dll.lib.nm 2011-10-25 20:44:21 +0200 @@ -21,15 +21,6 @@ I .idata$4 I .idata$5 I .idata$6 - T .text - U __IMPORT_DESCRIPTOR_ltdl-7 - I __imp__loadlibrary_LTX_get_vtable - T _loadlibrary_LTX_get_vtable - -ltdl-7.dll: - I .idata$4 - I .idata$5 - I .idata$6 ltdl-7.dll: I .idata$4 I'm not sure what the implication is, but I think it's benign. I suspect that the loadlibrary convenience lib is preloaded by libltdl and that stock 2.4.2 dllimports the symbol even though it's not really the right thing to do since the symbol is right there in the static convenience lib. However, and more importantly, I also found this in the build logs of both stock 2.4.2 and 2.4.2-no-lt-scope: cl -link -EXPORT:lt__alloc_die,DATA ... -link -EXPORT:lt_ltdl_LTX_preloaded_symbols,DATA ... So, there are indeed data exports in libltdl. Anyone trying to make use of those exports w/o LT_SCOPE doing the dllimport dance will probably fail. So, we need a test case exercising one or the other of those exports. Or both. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
Hi Gary, 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? [] The export decorator cannot be removed as is unknow how one project will build and try to export symbols. Please find attached file bootstrap.sh with test cases that show export functionality on windows platform gcc compiler - function export depend from export statement and export attribute: Test cases 1 are without export decorator as 1x export only one of functions. Application 1x fail to link Test cases 2 are with export attribute as 2x export only one of functions. Boot application will be linked due explicitly defined export attribute. Export of variables is other case . Also if export attribute is applied only to variables if I remember function will not be exported. Regards, Roumen bootstrap.sh Description: Bourne shell script bootstrap.sh.gz Description: GNU Zip compressed data ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
On 10/25/2011 11:51 AM, Gary V. Vaughan wrote: 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). Well, a couple of points: #1, libltdl is not normal: unlike most libraries, we provide explicit support for (a) linking externally, (b) incorporating as a subproject and linking locally (separate ./configure), and (c) incorporating as a submodule(?) and linking locally (combined ./configure). Very few other libraries support any such thing OOB. #2, I can think of one other GNU projects that support similar sub-inclusion: libintl. And /that/ library, and its cousin libiconv, also twist themselves into giant pretzels for Windows -- even moreso than libltdl. Bruno invented a whole new method of linking! http://www.haible.de/bruno/woe32dll.html BTW: one possible solution to this whole conundrum is to adopt Bruno's method [*], which works for both MSVC and gcc. The idea is to *always* declare exported symbols as declspec(dllimport), even when linking against the static library. The trick is, some additional build steps when building the library itself, to add the requisite import thunks to the static lib. See the URL above for more info. FWIW, Bruno has long said that this method would work better with just a few additional lines of code in libtool. However, as he's never actually posted just WHAT those additional lines of code would BE, I've been at a loss to move forward. That's been the status now for several years (not really high on my priority list). [*] without the -Wl,--disable-auto-import -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
