[Bug c++/111605] New: Cross compilation doesn't work with `-fuse-ld=mold`

[Bug c++/111605] New: Cross compilation doesn't work with `-fuse-ld=mold`

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

            Bug ID: 111605
           Summary: Cross compilation doesn't work with `-fuse-ld=mold`
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rui314 at gmail dot com
  Target Milestone: ---

When I pass `-fuse-ld=mold` to a gcc cross compiler, gcc searches for `ld.mold`
from the crosstool's bin directories and then looks for `<triple>-ld.mold` from
$PATH. Here is a gcc's strace when invoked with `-fuse-ld=mold`.

[pid 3905484] newfstatat(AT_FDCWD,
"/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/usr/lib/gcc-cross/riscv64-linux-gnu/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT
(No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/usr/lib/gcc-cross/riscv64-linux-gnu/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT
(No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/usr/lib/gcc-cross/riscv64-linux-gnu/11/../../../../riscv64-linux-gnu/bin/ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/.cargo/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/.local/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/.cabal/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/prefix/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/bin/qemu/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/ccache/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/golang/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/.mozbuild/node/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) =
-1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/home/ruiu/bin/depot_tools/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1
ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/usr/local/sbin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/usr/local/bin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/usr/sbin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/usr/bin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/sbin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/bin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/usr/games/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD,
"/usr/local/games/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT
(No such file or directory)
[pid 3905484] newfstatat(AT_FDCWD, "/snap/bin/riscv64-linux-gnu-ld.mold",
0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory)

This behavior is appropriate for BFD linker which has one executable for each
cross target. However, it's incorrect for the mold linker because mold supports
all targets by a single executable. Therefore, when gcc searches mold from
$PATH, it should look for just `ld.mold`, without the triple.

The same is true for LLD.

The link to the upstream bug: https://github.com/rui314/mold/issues/1114

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is by design. You can always just add a symbolic link in the right
location for ld.mold and it will work.

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #2 from Rui Ueyama <rui314 at gmail dot com> ---
I can make a change to the `make install` rule of the mold linker to install
bunch of symbolic links, but can we enumerate all possible triples? For
example, I wasn't aware that `arm-none-eabi` was a valid triple. If I enumerate
_all_ possible triples, wouldn't I end up with installing hundreds of symlinks?

And the tons of symbolic links wouldn't serve any meaningful purpose because
mold just ignores argv[0].

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Rui Ueyama from comment #2)
> I can make a change to the `make install` rule of the mold linker to install
> bunch of symbolic links, but can we enumerate all possible triples? For
> example, I wasn't aware that `arm-none-eabi` was a valid triple. If I
> enumerate _all_ possible triples, wouldn't I end up with installing hundreds
> of symlinks?

There are way too many (valid) triplets to list really and also the vendor
could be different and still be valid.

> 
> And the tons of symbolic links wouldn't serve any meaningful purpose because
> mold just ignores argv[0].

More likely the scripts which build the full toolchains directories should be
creating the symbolic links instead of mold itself.

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #4 from Rui Ueyama <rui314 at gmail dot com> ---
> More likely the scripts which build the full toolchains directories should be creating the symbolic links instead of mold itself.

So the package manager create a `<triple>-ld.mold` as a symlink to `mold` if
mold is installed? Or, should it create a `<triple>-ld.mold` unconditionally as
a symlink to `/usr/bin/mold`? If the latter, what if the user build mold
themselves and install it under `/usr/local/bin`?

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Rui Ueyama from comment #4)
> > More likely the scripts which build the full toolchains directories should be creating the symbolic links instead of mold itself.
> 
> So the package manager create a `<triple>-ld.mold` as a symlink to `mold` if
> mold is installed? Or, should it create a `<triple>-ld.mold` unconditionally
> as a symlink to `/usr/bin/mold`? If the latter, what if the user build mold
> themselves and install it under `/usr/local/bin`?

Most will not install it in /usr/* but for embedded toolchains will be
relocatable and installed in the same directory as the parts.

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #6 from Rui Ueyama <rui314 at gmail dot com> ---
Since mold supports all targets by a single executable, it doesn't make much
sense to install one mold executable for each embedded toolchain. So if we want
to keep the current gcc's lookup mechanism for `ld` executable, we want to
install mold somewhere in the system and install a symlink for each target, and
that's not compatible with relocatable emddeded toolchain directory. We need to
adjust the realpath of a symlink to point to the mold executable file.

All in all, the problem wouldn't exist at all if gcc just looks for `ld.mold`?
(I'm not suggesting making a change to the default behavior; I'd do that only
if `-fuse-ld=mold` or `-fuse-ld=lld` is givne.)

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Rui Ueyama from comment #6)
> Since mold supports all targets by a single executable, it doesn't make much
> sense to install one mold executable for each embedded toolchain.


You are wrong for support reasons. Especially when it comes to companies
providing toolchain support. Most don't want to be based on what is installed
on the system.

> 
> All in all, the problem wouldn't exist at all if gcc just looks for
> `ld.mold`? (I'm not suggesting making a change to the default behavior; I'd
> do that only if `-fuse-ld=mold` or `-fuse-ld=lld` is givne.)

This might be useful for a distro which provides all binaries but when it comes
to supporting embedded a target tighting control is better and not depending on
the installed version is always better.

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #8 from Rui Ueyama <rui314 at gmail dot com> ---
Sure, I agree with that. But would there be any problem if gcc, after failing
to find `<triple>-mold` and `mold` in the embedded toolchain's directory, looks
for `ld.mold` in the $PATH?"

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is only a problem when using a cross gcc, so why should mold proactively
create symlinks for dozens of targets when mold is installed?

It seems to me that a single symlink only needs to be created by the person
building the cross-gcc, and installed alongside $target-gcc as part of that
toolchain. This is not mold's problem, and could just be documented as part of
gcc's installation docs.

Although it probably does make sense for gcc to just fallback to using ld.mold
without the target prefix.

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #10 from Rui Ueyama <rui314 at gmail dot com> ---
> This is only a problem when using a cross gcc, so why should mold proactively create symlinks for dozens of targets when mold is installed?

It's because there are too many and we don't have an exhaustive list of all
possible triples. In particular, the vendor part of a triple (e.g. "none" in
"arm-none-eabi") can be anything IIUC, so we can't make an exhaustive list of
all triples.

> It seems to me that a single symlink only needs to be created by the person building the cross-gcc, and installed alongside $target-gcc as part of that toolchain. This is not mold's problem, and could just be documented as part of gcc's installation docs.

That's the correct solution if mold is bundled as part of the cross toolchain.
But if a user of the cross gcc toolchain wanted to use the system-installed
mold, they explicitly create a symbolic link in a $PATH by themselves at this
moment. I think that's pretty inconvenient.

> Although it probably does make sense for gcc to just fallback to using ld.mold without the target prefix.

Yeah, that's exactly what I want...

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |14.0
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-09-27

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, if you configure the cross target with --with-ld=ld.mold does that then
work (when not specifying -fuse-ld=mold)?

I suppose we could adjust how the driver(?) behaves, noting whether the linker
is multi-arch or not and at least allowing as fallback to use the "host"
specified linker.

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rui314 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #12 from Rui Ueyama <rui314 at gmail dot com> ---
> Hmm, if you configure the cross target with --with-ld=ld.mold does that then
> work (when not specifying -fuse-ld=mold)?

Sorry, I don't know, but in either case, that wouldn't solve the user-facing
problem when `-fuse-ld=mold` is explicitly passed.

> I suppose we could adjust how the driver(?) behaves, noting whether the linker
> is multi-arch or not and at least allowing as fallback to use the "host"
> specified linker.

Yes, please :)

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:1c6d6b34b112b52566ebde49afef3e6eb747ef90

commit r14-5281-g1c6d6b34b112b52566ebde49afef3e6eb747ef90
Author: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Date:   Mon Oct 16 14:04:12 2023 +0900

    Do not prepend target triple to -fuse-ld=lld,mold.

    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
            * collect2.cc (main): Do not prepend target triple to
            -fuse-ld=lld,mold.

[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |14.0
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Works on trunk now, queued for backporting up to GCC 12.