ziglang
ld.lld: warning: Linking two modules of different target triples ... arm-unknown-linux-musleabihf vs armv6kz-unknown-linux-musleabihf
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
We encountered the same problem when using MicroZig to build C files for arm
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?...)
The other looks like zig is failing to put the subarch into the llvm triple. This issue is to track the latter issue.
The problem still persists in 0.13 and i encountered it today when porting Ashet OS to Arm. I'll do a check if it still persists on the latest master state
