Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom built GCC search paths #1032

Open
firasuke opened this issue Apr 18, 2023 · 0 comments
Open

Custom built GCC search paths #1032

firasuke opened this issue Apr 18, 2023 · 0 comments

Comments

@firasuke
Copy link

firasuke commented Apr 18, 2023

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 and musl.

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant