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

[Martin Storsjö]

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

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

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