Re: Obsoleting LT_SCOPE

[Peter Rosin]

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