|
From: | Manoj Gupta |
Subject: | bug#27866: Handle clang's internal libraries when finding compiler's internal libraries |
Date: | Fri, 19 Jan 2018 17:34:58 -0800 |
On 28 Jul 2017 13:36, Manoj Gupta wrote:
> This is Manoj working on ChromeOS. I am facing a problem trying to build it
> with clang with its own internal library (compiler-rt) since some packages
> like mesa fail to build. The root cause is clang uses an absolute path to
> link its internal libraries which libtool does not recognize.
>
> e.g. clang++ -rtlib=compiler-rt main.cpp -v shows use of
> /usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins- x86_64.a
>
> Libtool currently relies on "-lname" pattern to find the internal
> libraries. And this does not work if some code is compiled using +
> compiler-rt.
> The issue was discovered in building mesa graphics library which uses
> -nostdlib flag and relies on libtool to pass the additionally required
> compiler internal libraries.
>
> I have a sample fix below for fixing this for clang.
>
> +--- a/m4/libtool.m4
> ++++ b/m4/libtool.m4
> +@@ -7531,7 +7544,7 @@
> + for p in `eval "$output_verbose_link_cmd"`; do
> + case $prev$p in
> +
> +- -L* | -R* | -l*)
> ++ -L* | -R* | -l* | *clang_rt*.a)
> + # Some compilers place space between "-{L,R}" and the path.
> + # Remove the space.
> + if test x-L = "$p" ||
> +
i don't think hardcoding any specific library is correct, especially with
an expansive glob like this.
i wonder if leveraging libext would be a bad idea here.
-L* | -R* | -l* | *.${libext})
-mike
[Prev in Thread] | Current Thread | [Next in Thread] |