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
