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

[Bob Friesenhahn]

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.

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

Actually, Windows DLL code does often require special options so that 
symbols are exposed and used in the correct way.  It may be that GCC 
and Clang help by automating symbol export and import in a way that 
compilers like Visual Studio / MSVC do not.  There are also often 
issues with exception handling since throwing exceptions across a DLL 
boundary is a special case, which historically has been handled in a 
couple of different ways by GCC.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt