[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: Bob Friesenhahn
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Date: Thu, 15 Aug 2019 08:01:47 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

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

reply via email to

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