[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27866: Handle clang's internal libraries when finding compiler's int

From: Martin Storsjö
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Date: Mon, 19 Aug 2019 13:44:57 +0300 (EEST)
User-agent: 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.

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

Attachment: 0001-Pick-up-clang_rt-static-archives-compiler-internal-l.patch
Description: Text Data

Attachment: 0002-Allow-statically-linking-compiler-support-libraries-.patch
Description: Text Data

reply via email to

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