-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
meson 0.52.0 breaks cross compilation due to linker "guess" #6057
Comments
Not passing the arguments in the cross file to the linker detection is very certainly a bug. |
…linkers There are at least two cases that we could run into here, one is someone could use an argument -fuse-ld=...; which would cause is to misdetect the linker being used. The other is that someone could use clang --target=, which will cause clang to use a different linker than without --target=; causing more mis-detection. Fixes mesonbuild#6057
What's the status of this one? Is that branch/commit going to fix the issue or does it need more work still? |
BTW |
…inker There are at least two cases that we could run into here, one is someone could use an argument -fuse-ld=...; which would cause is to misdetect the linker being used. The other is that someone could use clang --target=, which will cause clang to use a different linker than without --target=; causing more mis-detection. This considers environment variables, -D<lang>_args, and both cross and native file appropriately. This patch is very much not perfect, there's some code duplication and some "working around the design" going on. That needs to be addressed, but this unbreaks things, and thats good. Fixes mesonbuild#6057
Ok, I've changed approaches and things seem to be working much better. I still need to implement the fix for windows/msvc. |
and write some tests and error handling. |
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
As a note, you can work around this right now with symlinks, clang understands that |
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll get ld.gold, not whatever the default is. Meson currently doesn't do that, because it doesn't pass these arguments to the linker detection logic. This patch fixes that. Another case that this is needed is with clang's --target option This is a bad solution, honestly, and it would be better to use $LD or a cross/native file but this is needed for backwards compatability. Fixes mesonbuild#6057
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll get ld.gold, not whatever the default is. Meson currently doesn't do that, because it doesn't pass these arguments to the linker detection logic. This patch fixes that. Another case that this is needed is with clang's --target option This is a bad solution, honestly, and it would be better to use $LD or a cross/native file but this is needed for backwards compatability. Fixes mesonbuild#6057
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll get ld.gold, not whatever the default is. Meson currently doesn't do that, because it doesn't pass these arguments to the linker detection logic. This patch fixes that. Another case that this is needed is with clang's --target option This is a bad solution, honestly, and it would be better to use $LD or a cross/native file but this is needed for backwards compatability. Fixes mesonbuild#6057
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll get ld.gold, not whatever the default is. Meson currently doesn't do that, because it doesn't pass these arguments to the linker detection logic. This patch fixes that. Another case that this is needed is with clang's --target option This is a bad solution, honestly, and it would be better to use $LD or a cross/native file but this is needed for backwards compatability. Fixes mesonbuild#6057
I've moved this from 0.52.2 to 0.53.0, as (I think) we've decided the size of the changes are too large to go into a stable release. There's a bunch of other linker related stuff in the 0.53.0 milestone now. |
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll get ld.gold, not whatever the default is. Meson currently doesn't do that, because it doesn't pass these arguments to the linker detection logic. This patch fixes that. Another case that this is needed is with clang's --target option This is a bad solution, honestly, and it would be better to use $LD or a cross/native file but this is needed for backwards compatability. Fixes mesonbuild#6057
This uses the normal meson mechanisms, an LD environment variable or via cross/native files. Fixes: mesonbuild#6057
I can reproduce the same issue after upgrading to 0.52.0 that I needed for macOS Catalina fixes. I tried the following workarounds:
The linker is still miss-detected as APPLE LD |
I understand I would need #6207 to override the linker in the [binaries] section. |
Linking is broken with Meson 0.52 mesonbuild/meson#6057 CLang detection for macOS Catalina's version is broken with Meson 0.49 We keep 0.52 except when targetting Android that we build for 0.49
With meson 0.52.0, there is a new function _guess_nix_linker in environment.py that attempts to guess the linker being used; it does this by passing -Wl,--version to the compiler, but as it doesn't pass the various compiler flags added in a --cross-file, it returns the default linker for the build system instead of the chosen linker for the host system (which might be the default for a --target or might be a specific override due to -B or -fuse-ld). This worked fine with 0.51.1.
In my case, I have the following --cross-file, which uses clang from the Android NDK and overrides --target, at which point it will use a GNU linker (sometimes gold); by default, however, this version of clang will happily compile for macOS, and so will run ld64 if no arguments are passed. (FWIW, I partly include this as maybe I'm using the arguments wrong, like maybe I need to be putting these --target arguments somewhere more fundamental than merely c_args?)
Here is the output from meson, instrumenting the run process with RUNNING lines.
The resulting issue, btw, is that I end up with Apple-specific flags being passed to my Android compiler, and Apple-specific file extensions being used for my libraries; I thereby end up with -dead_strip_dylibs (which isn't supported by this compiler, but is hilariously parsed as a kind of symbol to define and re-export) and .dylib. Here's an example LINK_ARGS from the resulting build.ninja (this is a compile of glib).
The text was updated successfully, but these errors were encountered: