[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27866: Handle clang's internal libraries when finding compiler's int
bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Fri, 16 Aug 2019 00:06:56 +0300 (EEST)
Alpine 2.20 (DEB 67 2015-01-07)
On Thu, 15 Aug 2019, Bob Friesenhahn wrote:
On Thu, 15 Aug 2019, Martin Storsjö wrote:
But on Windows, the DLLs aren't allowed to have undefined references, so
that mechanism of deferring linking of certain libraries don't work there.
(And shouldn't this mechanism be sidestepped altogether if linking with
-no-undefined in general?)
Libraries provided by the compiler should have a special status since they
are built in a well-defined way and it should be possible to make assumptions
about their suitability for use. The failure to ascribe this special status
appears to be the problem here.
Hmm, ok... Is there code in libtool that actually tries to make this
distinction, that should be adjusted so that it triggers here as well, or
is that just a general thing that would be sensible to have?
Additionally, I don't know of any special options that need to be used to
build code for a shared library on Windows (either MSVC or mingw), as e.g.
-fPIC doesn't apply on windows at all. So given that, it seems to me that
lt_cv_deplibs_check_method=pass_all on windows/mingw should be safe?
Actually, Windows DLL code does often require special options so that symbols
are exposed and used in the correct way. It may be that GCC and Clang help
by automating symbol export and import in a way that compilers like Visual
Studio / MSVC do not.
Right, yes, the use or lack of dllimport is an issue, yes. But that
doesn't mean one can't/shouldn't link to static libraries when building a
shared one either, it only implies that one has to link against one that
matches the attributes used when compiling the calling code.
And yes, GCC/Clang and ld.bfd and lld have special code that make most of
this issue go away (making dllimport essentially unnecessary).
There are also often issues with exception handling since throwing
exceptions across a DLL boundary is a special case, which historically
has been handled in a couple of different ways by GCC.
Yeah, that's also a big potential issue.
But as far as I know, libtool doesn't actually check for either of these
issues at the momemnt anyway, or does it? I.e. does the dependency check
actually help detecting any of these issues specifically, or just refuse
to link in static libraries in general (in certain cases) when building a