Re: [PATCH v2 01/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

[Richard Purdie]

On Wed, 2022-04-20 at 01:12 +0100, Sam James wrote:
> 
> > On 17 Apr 2022, at 05:55, Alex Ameen <alex.ameen.tx@gmail.com> wrote:
> > 
> > This was all green down the line on the test suite on multiple systems (
> > don't get too excited yet ) until I found bugs in the testsuite...
> > 
> > I see how this flew under the radar previously though - currently there are
> > no tests which attempt to check RPATH or RUNPATH entries. I'll definitely be
> > working on that... I'm going to be working out some M4 macros to abstract
> > some functions like `lt_read_pheader([BIN], [ENTRY])',
> > `lt_read_rpath([BIN])', and `lt_read_runpath([BIN])', so that those can be
> > abstracted for handling non-ELF binaries.
> > 
> > I'll make a test case to the effect of `readelf -d -W BIN|grep -v
> > "$sysroot/";', if you have any additional input on new test cases let me
> > know.
> > 
> > You also helped me catch some bad regex in the existing sysroot tests that
> > would cause them to never be run on a system which used '/' as their GCC
> > sysroot ( all of dpkg's  cross compilers seem to... ).
> 
> Nice! I've found a *lot* of things don't respect this case, actually.
> 
> > 
> > So a big thank you for helping to catch all of these places that the tool
> > can be improved.
> > 
> > Naturally now that test cases aren't skipped they're red, so once I sanity
> > check that they fail on the mainline branch I can move forward. I'm ~99%
> > sure this patch will have no effect on those results.
> > 
> > 
> 
> FWIW, given the comments on the main libtool ML, I at least am happy to drop
> this one for now, and revisit later. Richard might feel differently though.

I think this one is ok, it would be "ltmain.in: Don't encode RATHS which match
default linker paths" which is being questioned. We see a awful lot of it and I
don't think we need them but I can see the concern others are raising even if it
what I think should be a more unusual use case. It may be something that could
be configured ultimately?

> I like incremental progress so the more easy stuff in, the better, even if it
> means we have to come back to some of the harder ones.

Definitely agreed. I'd rather we make progress on the things we can agree on
that block on that.

Cheers,

Richard