You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was trying to configure the toolchain to use mold as its linker, and I was successful. However, I faced some issues.
Here are my notes on how I fixed those issues:
Custom built GCCs have custom search directories. Even though I have version 12.2.0, adding -fuse-ld=mold was not sufficient for my custom gcc to find the host's mold (provided by distribution's package manager) or my custom mold (as I was getting the following error collect2: fatal error: cannot find 'ld' mold, which is why I had to add -B/path/to/directory/where/custom/mold/is to my CFLAGS along with -fuse-ld=mold to get it working.
Most packages linked just fine, until I stumbled upon packages which used autoreconf and libtool to create .la files. Apparently libtool likes to strip flags when linking. This was troublesome because I am passing -B/path/to/directory/where/custom/mold/is in my CFLAGS and it was being removed, so my custom gcc could no longer find mold, giving the same error as above.
You can workaround this by modifying GCC_EXEC_PREFIX which is not desirable for many reasons.
The solution I found was to provide a symbolic link to mold in the search directories of the custom built gcc (which can be listed by running gcc -print-search-dirs).
The symbolic link was installed in /custom/toolchain/tuple/bin where binutils already keeps its hardlinks to ../../bin including ld.bfd, which is why I issued the command ln -fs ../../bin/mold /custom/toolchain/tuple/bin/ld.mold.
I understand that this is not an upstream issue, but I thought it would help those who encounter a similar issue in the future.
One suggestion I have is to add a note to the documentation (the section where it talks about installing / running / using mold) reminding users who are working with custom toolchains to include mold in their compiler's custom search directory.
Keep up the great work!
The text was updated successfully, but these errors were encountered:
Hey there, I'd like to thank you for your time and for your work on the mold linker.
I am working on an independent Linux distribution, where I have a custom built toolchain that utilizes
gcc
andmusl
.I was trying to configure the toolchain to use
mold
as its linker, and I was successful. However, I faced some issues.Here are my notes on how I fixed those issues:
12.2.0
, adding-fuse-ld=mold
was not sufficient for my customgcc
to find the host'smold
(provided by distribution's package manager) or my custommold
(as I was getting the following errorcollect2: fatal error: cannot find 'ld' mold
, which is why I had to add-B/path/to/directory/where/custom/mold/is
to myCFLAGS
along with-fuse-ld=mold
to get it working.autoreconf
andlibtool
to create.la
files. Apparentlylibtool
likes to strip flags when linking. This was troublesome because I am passing-B/path/to/directory/where/custom/mold/is
in myCFLAGS
and it was being removed, so my customgcc
could no longer findmold
, giving the same error as above.GCC_EXEC_PREFIX
which is not desirable for many reasons.mold
in the search directories of the custom builtgcc
(which can be listed by runninggcc -print-search-dirs
)./custom/toolchain/tuple/bin
wherebinutils
already keeps its hardlinks to../../bin
includingld.bfd
, which is why I issued the commandln -fs ../../bin/mold /custom/toolchain/tuple/bin/ld.mold
.I understand that this is not an upstream issue, but I thought it would help those who encounter a similar issue in the future.
One suggestion I have is to add a note to the documentation (the section where it talks about installing / running / using
mold
) reminding users who are working with custom toolchains to includemold
in their compiler's custom search directory.Keep up the great work!
The text was updated successfully, but these errors were encountered: