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

Mike Frysinger <[email protected]> Fri, 19 Jan 2018 17:16:19 -0500

Newsgroups	gmane.comp.gnu.libtool.bugs
Message-ID	<20180119221619.GM7217@vapier>

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

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

signature.asc (application/pgp-signature, 833 B)