bug-libtool
[Top][All Lists]
Advanced

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

I think that both .a and .so libraries should be handled here. Will *.${libext} handle both cases?

On Fri, Jan 19, 2018 at 2:16 PM, Mike Frysinger <address@hidden> wrote:
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


reply via email to

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