search

ziglang / zig

General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
https://ziglang.org
MIT License
34.65k stars 2.53k forks source link

ld.lld: warning: Linking two modules of different target triples ... arm-unknown-linux-musleabihf vs armv6kz-unknown-linux-musleabihf #14962

Open andrewrk opened 1 year ago

andrewrk commented 1 year ago

Extracted from https://github.com/ziglang/zig/pull/14647.

There are two problems here. One is https://github.com/ziglang/zig/issues/14908. The other looks like zig is failing to put the subarch into the llvm triple. This issue is to track the latter issue.

ld.lld: warning: Linking two modules of different target triples: '/home/andy/Downloads/zig/zig-cache/o/610cf441612621c1d4bea0844fb8daea/test.o' is 'arm-unknown-linux-musleabihf' whereas 'ld-temp.o' is 'armv6kz-unknown-linux-musleabihf'

https://github.com/ziglang/zig/blob/b4d58e93ea4d0bbfe674f80d301279d302fe8fc8/test/tests.zig#L1019-L1066

ikskuh commented 1 year ago

We encountered the same problem when using MicroZig to build C files for arm

cfillion commented 5 months ago

Same issue here: building for ARM with some C sources. Disabling LTO works around it. An empty .c file + test.zig with only the entry point is enough to trigger the issue:

export fn _start() void {}
$ zig version
0.12.0
$ zig build-exe -target thumb-freestanding-eabihf test.zig empty.c -flto
LLD Link... warning(link): unexpected LLD stderr:
ld.lld: warning: Linking two modules of different target triples: 'test.o' is 'thumb-unknown-unknown-eabihf' whereas 'ld-temp.o' is 'thumbv6kz-unknown-unknown-eabihf'
$ zig build-exe -target thumb-freestanding-eabihf test.zig empty.c -fno-lto
# (success, no output)

zig build reports any linker stderr output as an error (error: warning(link): unexpected LLD stderr:), but since linking actually succeeded, it isn't re-done on subsequent invocations, so the error about LLD's warning only reappears the next time something else changes to trigger linking. (That seems like its own bug: errors should not vanish until solved or perhaps linker warnings should not be reported as an error in the first place?...)