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