bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Martin Storsjö <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <[email protected]> |
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. I tried implementing this, see patch attached patch 2. It's not exactly great to explicitly have to list libraries by name like libgcc* and libclang_rt*, but the existing general mechanisms like deplibs_check_method aren't really used fully here (if deplibs_check_method="file_magic ...", then the static library is just outright rejected without even inspecting it). Or should this case be extended to also try file_magic if that's what has been chosen, and then put the special case code for libclang_rt in e.g. func_win32_libid? (But that wouldn't work for the other mingw case that uses $OBJDUMP -f instead of func_win32_libid.) I also tried updating Manoj's original patch with the suggestions from Mike earlier in this discussion thread in attach patch 1. // Martin _______________________________________________ Bug-libtool mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-libtool
0001-Pick-up-clang_rt-static-archives-compiler-internal-l.patch
(text/x-diff, 1.2 KB)
From 8e8607e8a6902a2d374b3f54084c2b68a1ade541 Mon Sep 17 00:00:00 2001 From: Manoj Gupta <[email protected]> Date: Wed, 10 Oct 2018 10:50:23 +0300 Subject: [PATCH 1/2] Pick up clang_rt static archives compiler internal libraries Libtool checks only for libraries linked as -l* when trying to find internal compiler libraries. Clang, however uses the absolute path to link its internal libraries e.g. compiler_rt. This patch handles clang's statically linked libraries when finding internal compiler libraries. https://crbug.com/749263 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866 --- m4/libtool.m4 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index b55a6e57..e6fc29bb 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -7553,10 +7553,11 @@ if AC_TRY_EVAL(ac_compile); then # the conftest object file. pre_test_object_deps_done=no + eval std_shrext=\"$shrext_cmds\" for p in `eval "$output_verbose_link_cmd"`; do case $prev$p in - -L* | -R* | -l*) + -L* | -R* | -l* | *.${libext} | *${std_shrext}) # Some compilers place space between "-{L,R}" and the path. # Remove the space. if test x-L = "$p" || -- 2.17.1
0002-Allow-statically-linking-compiler-support-libraries-.patch
(text/x-diff, 1.3 KB)
From b9f77cae8cfbe850e58cac686fcb4d246b5bfc51 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Storsj=C3=B6?= <[email protected]> Date: Mon, 19 Aug 2019 13:34:51 +0300 Subject: [PATCH 2/2] Allow statically linking compiler support libraries when linking a library For cases with deplibs_check_method="file_magic ..." (as it is for mingw), there were previously no way that a static library could be accepted here. --- build-aux/ltmain.in | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index e2fb2633..db4d775c 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -5870,8 +5870,15 @@ func_mode_link () fi case $linkmode in lib) - # Linking convenience modules into shared libraries is allowed, - # but linking other static libraries is non-portable. + # Linking convenience modules and compiler provided static libraries + # into shared libraries is allowed, but linking other static + # libraries is non-portable. + case $deplib in + */libgcc*.$libext | */libclang_rt*.$libext) + deplibs="$deplib $deplibs" + continue + ;; + esac case " $dlpreconveniencelibs " in *" $deplib "*) ;; *) -- 2.17.1