[cfe-dev] clang uses absolute path for linking compiler-rt libraries

[Saleem Abdulrasool via cfe-dev]

On Fri, Jan 19, 2018 at 3:20 PM, Manoj Gupta via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> When using compiler-rt with clang, clang uses abolute path of compiler-rt
> libraries to pass to linker
> e.g. $ clang -v -rtlib=compiler-rt main.o -o main
> "/usr/bin/x86_64-pc-linux-gnu-ld" ....  -lc /usr/lib64/clang/6.0.0/lib/
> linux/libclang_rt.builtins-x86_64.a
>
> Is there any particular reason clang does not use the format "-L/path"
> and  "-lname" e.g. -L/usr/lib64/clang/6.0.0/lib/linux -lclang_rt.builtins-x86_64?
> I assume there must be a good reason but could not find one by searching
> llvm-dev archives (I might  be searching using wrong keywords).
>
> The reason I am asking is certain build tools like libtool parses "-l" or
> "-L" strings in compiler's output to determine the default compiler
> libraries. Since compiler-rt libraries are specified using absolute path,
> it doesn't add compiler-rt libraries to its list of libs that must be
> explicitly linked. The missing libraries becomes an issue if  final linking
> is done with -nostdlib since the generated binary will miss the symbols
> provided by builtins.
>

One reason that I can think of is safety.  By using the absolute path, the
library path search order is not considered and thus you can be sure that
the right version of the library will be used.  Because the builtins and
the sanitizer runtimes are pretty closely tied to the compiler, it is
better if it can ensure that the right version of the library is used.


> For reference, these are some of the ChromeOS bugs where we faced this
> issue https://crbug.com/749263, https://crbug.com/802091.
>
> Thanks,
> Manoj
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180119/5f300dda/attachment.html>