[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
Thu, 15 Aug 2019 17:56:44 +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:
So, it basically boils down to, what the actual purpose of inspecting
dependency libs is (what real scenario does it protect from), as it breaks
linking to compiler_rt's builtins (which are referred to as an absolute
path to the .a file)?
The purpose of inspecting dependency libs is that often code needs to be
compiled with special options (e.g. for PIC code) in order to function in
shared libraries or DLLs. Code which was compiled properly can be included
in the shared library but code which lacks the necessary options needs to be
saved for later and linked directly with the dependent program. Libtool's
".la" files contain enough information that libtool can make the correct
decision when a dependent program is linked.
If code which is not prepared for use in a shared library is included into
the shared library, the linking may fail, or the program may crash, or run
Ah, thanks for the explanation. Ok, if libtool has the ability to defer
the use of such libraries to the the executable instead of the shared
library, that's clearly neat.
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?)
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?
Since clang is intended to be gcc compatible, it would be most useful for
clang and its linker to emulate the GNU equivalents closely enough that
existing build infrastructure does not need to change.
Yes, that would of course be ideal, but for various reasons it doesn't
always happen to the full extent.
In general, clang does link to libgcc just like gcc does, by passing
-L<gccdir> -lgcc, but when using compiler_rt, it does so by passing the
full absolute path to the static library instead.
I started out making a patch for changing this some time ago, but there
were arguments against it; apparently it's deemed a safety feature to be
more exact in how the compiler_rt libraries are specified: