On Thu, 9 Nov 2023, Tatsuyuki Ishi wrote: > > On Nov 7, 2023, at 23:37, Richard Biener <rguent...@suse.de> wrote: > > > > On Tue, 7 Nov 2023, Tatsuyuki Ishi wrote: > > > >>> On Oct 16, 2023, at 18:16, Richard Biener <rguent...@suse.de> wrote: > >>> > >>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: > >>> > >>>> > >>>> > >>>>> On Oct 16, 2023, at 17:55, Richard Biener <rguent...@suse.de> wrote: > >>>>> > >>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>>> On Oct 16, 2023, at 17:39, Richard Biener <rguent...@suse.de> wrote: > >>>>>>> > >>>>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: > >>>>>>> > >>>>>>>> lld and mold are platform-agnostic and not prefixed with target > >>>>>>>> triple. > >>>>>>>> Prepending the target triple makes it less likely to find the > >>>>>>>> intended > >>>>>>>> linker executable. > >>>>>>>> > >>>>>>>> A potential breaking change is that we no longer try to search for > >>>>>>>> triple-prefixed lld/mold binaries anymore. However, since there > >>>>>>>> doesn't > >>>>>>>> seem to be support to build LLVM or mold with triple-prefixed > >>>>>>>> executable > >>>>>>>> names, it seems better to just not bother with that case. > >>>>>>>> > >>>>>>>> PR driver/111605 > >>>>>>>> > >>>>>>>> gcc/Changelog: > >>>>>>>> > >>>>>>>> * collect2.cc (main): Do not prepend target triple to > >>>>>>>> -fuse-ld=lld,mold. > >>>>>>>> --- > >>>>>>>> gcc/collect2.cc | 13 ++++++++----- > >>>>>>>> 1 file changed, 8 insertions(+), 5 deletions(-) > >>>>>>>> > >>>>>>>> diff --git a/gcc/collect2.cc b/gcc/collect2.cc > >>>>>>>> index 63b9a0c233a..c943f9f577c 100644 > >>>>>>>> --- a/gcc/collect2.cc > >>>>>>>> +++ b/gcc/collect2.cc > >>>>>>>> @@ -865,12 +865,15 @@ main (int argc, char **argv) > >>>>>>>> int i; > >>>>>>>> > >>>>>>>> for (i = 0; i < USE_LD_MAX; i++) > >>>>>>>> - full_ld_suffixes[i] > >>>>>>>> #ifdef CROSS_DIRECTORY_STRUCTURE > >>>>>>>> - = concat (target_machine, "-", ld_suffixes[i], NULL); > >>>>>>>> -#else > >>>>>>>> - = ld_suffixes[i]; > >>>>>>>> -#endif > >>>>>>>> + /* lld and mold are platform-agnostic and not prefixed with > >>>>>>>> target > >>>>>>>> + triple. */ > >>>>>>>> + if (!(i == USE_LLD_LD || i == USE_MOLD_LD)) > >>>>>>>> + full_ld_suffixes[i] = concat (target_machine, "-", > >>>>>>>> ld_suffixes[i], > >>>>>>>> + NULL); > >>>>>>>> + else > >>>>>>>> +#endif > >>>>>>>> + full_ld_suffixes[i] = ld_suffixes[i]; > >>>>>>>> > >>>>>>>> p = argv[0] + strlen (argv[0]); > >>>>>>>> while (p != argv[0] && !IS_DIR_SEPARATOR (p[-1])) > >>>>>>> > >>>>>>> Since we later do > >>>>>>> > >>>>>>> /* Search the compiler directories for `ld'. We have protection > >>>>>>> against > >>>>>>> recursive calls in find_a_file. */ > >>>>>>> if (ld_file_name == 0) > >>>>>>> ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], > >>>>>>> X_OK); > >>>>>>> /* Search the ordinary system bin directories > >>>>>>> for `ld' (if native linking) or `TARGET-ld' (if cross). */ > >>>>>>> if (ld_file_name == 0) > >>>>>>> ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], > >>>>>>> X_OK); > >>>>>>> > >>>>>>> I wonder how having full_ld_suffixes[LLD|MOLD] == > >>>>>>> ld_suffixes[LLD|MOLD] > >>>>>>> fixes anything? > >>>>>> > >>>>>> Per the linked PR, the intended use case for this is when one wants to > >>>>>> use their system lld/mold with a separately packaged cross toolchain, > >>>>>> without requiring them to symlink their system lld/mold into the cross > >>>>>> toolchain bin directory. > >>>>>> > >>>>>> (Note that the first search is against COMPILER_PATH while the latter > >>>>>> is > >>>>>> against PATH). > >>>>> > >>>>> Ah. So what about instead adding here > >>>>> > >>>>> /* Search the ordinary system bin directories for mold/lld even in > >>>>> a cross configuration. */ > >>>>> if (ld_file_name == 0 > >>>>> && selected_linker == ...) > >>>>> ld_file_name = find_a_file (&path, ld_suffixes[selected_linker], > >>>>> X_OK); > >>>>> > >>>>> instead? That would keep things working in case the user has a > >>>>> xyz-arch-mold in the system dir but uses GNU ld on the host > >>>>> otherwise, lacking a 'mold' binary there? > >>>>> > >>>>> That is, we'd only add, not change what we search for. > >>>> > >>>> I considered that, but as described in commit message, it doesn?t seem > >>>> anyone has created stuff named xyz-arch-lld or xyz-arch-mold. Closest is > >>>> Gentoo?s symlink mentioned in this thread, but that?s xyz-arch-ld -> > >>>> ld.lld/mold. > >>>> As such, this feels like a quirk, not something we need to keep > >>>> compatibility for. > >>> > >>> I don't have a good idea whether this is the case or not unfortunately > >>> so if it's my call I would err on the safe side. > >>> > >>> We seem to recognize mold and lld only since GCC 12 which both are > >>> still maintained so I think we might want to do the change on all > >>> those branches? > >>> > >>> If you feel confident there's indeed no such installs then let's go > >>> with your original patch. > >>> > >>> Thus, OK for trunk and the affected branches after a while of no > >>> reported issues. > >> > >> Hi, > >> > >> Can I consider this an approval for this patch to be applied to trunk? > > > > Yes. > > > >> I would appreciate if this patch could be tested in GCC 14 prereleases. > >> > >> I suppose backporting after no reported issues in GCC 14 would be the plan > >> here? > >> > >> Please let me know in case of misunderstandings. > > > > You understood correctly. > > > > Richard. > > Hi Richard, > > I forgot to mention that I don?t have committer / write access. > > Could you help me get this patch committed? Thanks.
I pushed it to trunk sofar. Richard. > > Tatsuyuki. > > >> Thanks, > >> Tatsuyuki. > >> > >>> Thanks, > >>> Richard. > >>> > >>>> The proposed change seems simple enough though, so if you consider this > >>>> a compatibility issue I can go for that way as well. > >>> > >>>> Tatsuyuki. > >>>> > >>>>> > >>>>> Thanks, > >>>>> Richard. > >>>> > >>>> > >>> > >>> -- > >>> Richard Biener <rguent...@suse.de <mailto:rguent...@suse.de> > >>> <mailto:rguent...@suse.de>> > >>> SUSE Software Solutions Germany GmbH, > >>> Frankenstrasse 146, 90461 Nuernberg, Germany; > >>> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) > >> > >> > > > > -- > > Richard Biener <rguent...@suse.de <mailto:rguent...@suse.de>> > > SUSE Software Solutions Germany GmbH, > > Frankenstrasse 146, 90461 Nuernberg, Germany; > > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
