-
Notifications
You must be signed in to change notification settings - Fork 979
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
[feature] Allow specifying the linker in tools.build:compiler_executables #14174
Comments
Hi @jwillikers Thanks for your suggestion. I'd like to see how the info is passed to the different build systems. If you are willing to give this feature a try, please let us know, otherwise it might need to wait a bit, as there are already too many higher priorities ongoing. Thanks! |
I might find time before the team gets around to it. I'll update if / when I start work on it. |
I think I have a better understanding of how to best solve this now. I think that instead of using CMake 3.29 introduced the CMAKE_LINKER_TYPE variable which can be used to configure the linker. This can be set to values such as Given the CMake and Meson ways of setting the linker,
Conan will probably also want to take into account compiler versions and linker support as is done by CMake and Meson. I ran into this with the Limitations of the current solution I've proposed here include the inability to override the actual linker executable, which I think some consumers may still wish to do and the fact that this only addresses CMake and Meson, but not Autotools or msbuild. |
From my comment in #: Until the most recently released CMake version 3.29, there is no way to tell CMake which linker to use - bear in mind that CMake uses the compiler to perform the link step, rather than invoking the linker directly. We are considering how to best integrate the new CMAKE_LINKER_TYPE In the meantime, I suspect the easiest way to achieve a different linker globally across all generators, is to use the Alternatively, if you're only targetting CMake, you can use a custom toolchain file that contains the line
The compiler is "hardwired" to find the linker in some specified way. When cross-compiling, this will try and find the linker that is part of the same toolchain, and should not use the system default at all.
At least for gcc, |
What works now is compiling llvm with I override
It'd be great if the conan |
This would be really great. I've noticed that setting CMAKE_LINKER_TYPE doesn't do anything when using Conan, I guess the linker is being set somewhere else in the toolchain file. |
To use mold as the default linker, you can consider: |
I'm not sure if I'm doing it right, but I seem to be getting an error with this:
|
What is your suggestion?
There are use cases for using a linker other than the system default, such as cross-compilation and link-time optimization.
Currently, users must specify the linker through build-system dependent environment variables using the
[buildenv]
section.Build systems do not uniformly make use of the
LD
environment variable to define the linker, which leads to confusion.Meson, for instance, uses different environment variables than the common
LD
environment variable, which has lead to the issues #13824 and #14028.Furthermore, build systems may provide more robust methods of specifying the linker than using environment variables.
Meson, for instance, allows defining the linker in cross and native files, which are already generated by Conan.
This is described here.
Allowing a linker to be specified via
tools.build:compiler_executables
would unify specification of the linker and reduce confusion and duplication.Meson allows defining a linker for both the C and C++ languages, so I would propose that we do the same in
tools.build:compiler_executables
, i.e.c_ld
andcpp_ld
.CMake and Autotools toolchains should be able to make use of these values as well.
Have you read the CONTRIBUTING guide?
The text was updated successfully, but these errors were encountered: