Sam James <s...@gentoo.org> writes: > Eric Gallager <eg...@gwmail.gwu.edu> writes: > >> On Wed, Aug 14, 2024 at 8:50 AM Sam James <s...@gentoo.org> wrote: >>> >>> libtool defaults to filtering flags passed at link-time. >>> >>> This brings the filtering in GCC's 'fork' of libtool into sync with >>> upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e. >> >> I think it'd be worthwhile to link to the upstream commit in the >> ChangeLog / commit message, too. Also, are you sure that's the right >> one? It looks just like a version revbump commit to me: >> https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e > > 'as of' meaning "this is the state of the repository when I > checked", so if you want to check my work, you should checkout > libtool.git at that commit and compare the product. > > There is no single commit which does this, it was done over > many commits over many years. It's not worth trying to dig those many > commits up, IMO.
... and of course, I made an error. While the explanation above is correct, I actually missed 40b73c116e4f1c94b8f6c4ab60c7ec2036611fc6. But the flags it adds aren't that interesting for us anyway. If approved, I'll commit it with that variant if it's fine (which adds -fcilkplus and -static-*). Ultimately, this patch should overall be low-risk given it's not *adding* flags, and if a flag is problematic, we should filter it long-before libtool's link stage anyway. It's mostly about correctness for LTO option merging.
signature.asc
Description: PGP signature
