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

Hi Alex,

I've understood you're a new maintainer of libtool. Can you have a look at 
this bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27866)?

In the last few posts, there's a couple patches attached. They have been 
used downstream within e.g. MSYS2 since a couple years:

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0011-Pick-up-clang_rt-static-archives-compiler-internal-l.patch

https://github.com/msys2/MSYS2-packages/blob/master/libtool/0013-Allow-statically-linking-compiler-support-libraries-.patch

// Martin


On Mon, 19 Aug 2019, Martin Storsjö wrote:

> 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.

_______________________________________________
Bug-libtool mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-libtool