libtool
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]