[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Obsoleting LT_SCOPE
From: |
Peter Rosin |
Subject: |
Re: Obsoleting LT_SCOPE |
Date: |
Mon, 31 Oct 2011 13:16:37 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 |
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
Re: Obsoleting LT_SCOPE, Bob Friesenhahn, 2011/10/25
Re: Obsoleting LT_SCOPE, Charles Wilson, 2011/10/25
Re: Obsoleting LT_SCOPE, Roumen Petrov, 2011/10/25