[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 12:54:11 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 |
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
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