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

On Thu, 15 Aug 2019, Martin Storsjö wrote:
>
> So, it basically boils down to, what the actual purpose of inspecting 
> dependency libs is (what real scenario does it protect from), as it breaks 
> linking to compiler_rt's builtins (which are referred to as an absolute path 
> to the .a file)?

The purpose of inspecting dependency libs is that often code needs to 
be compiled with special options (e.g. for PIC code) in order to 
function in shared libraries or DLLs.  Code which was compiled 
properly can be included in the shared library but code which lacks 
the necessary options needs to be saved for later and linked directly 
with the dependent program.  Libtool's ".la" files contain enough 
information that libtool can make the correct decision when a 
dependent program is linked.

If code which is not prepared for use in a shared library is included 
into the shared library, the linking may fail, or the program may 
crash, or run very inefficiently.

Since clang is intended to be gcc compatible, it would be most useful 
for clang and its linker to emulate the GNU equivalents closely enough 
that existing build infrastructure does not need to change.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

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