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

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 <[email protected]> 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
>

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