compilers: Do not pass -fuse-ld=lld via -Wl,

[lhmouse]

-fuse-ld= is a driver option for selection of a linker; it shall not be passed to a linker with -Wl,.

Previously, using Clang-CL and LLD-LINK, given:

cc = meson.get_compiler('c')
assert(cc.has_link_argument('/LTCG'))

This code failed to detect the /LTCG option, because -fuse-ld was passed to the linker, as an invalid option:

Command line: clang E:\lh_mouse\Desktop\t\build\meson-private\tmpg0221f ee\testfile.c -o E:\lh_mouse\Desktop\t\build\meson-private\tmpg0221fee\o utput.exe -D_FILE_OFFSET_BITS=64 -O0 -Werror=implicit-function-declarati on -Wl,-WX -Wl,/LTCG -Wl,-fuse-ld=lld -> 4044
stdout:
LINK : warning LNK4044: unrecognized option '/fuse-ld=lld'; ignored
LINK : error LNK1218: warning treated as error; no output file generated

[eli-schwartz]

I was initially trying to figure out why this was required at all. Then it hit me -- the linker_to_compiler_args function defines how to translate linker flags for microsoft platform linkers, which might expect to be passed to link.exe, such that e.g. clang when acting as the linker driver will forward those flags on to the real linker.

That's why we don't expect the flags to automatically come with -Wl, and correspondingly why we would add -Wl, ourselves. Which is therefore why we need to explicitly exclude -fuse-ld...

Can you mention that in the commit message?

P.S. When quoting "Command line: XXXX" etc. as snippets from a logfile, the 80-columns convention doesn't apply (actually, the convention itself says that this is an exception), just enclose it in triple-backticks and carry on. :)

[lhmouse]

I was initially trying to figure out why this was required at all. Then it hit me -- the linker_to_compiler_args function defines how to translate linker flags for microsoft platform linkers, which might expect to be passed to link.exe, such that e.g. clang when acting as the linker driver will forward those flags on to the real linker.

That's why we don't expect the flags to automatically come with -Wl, and correspondingly why we would add -Wl, ourselves. Which is therefore why we need to explicitly exclude -fuse-ld...

Can you mention that in the commit message?

Done now. A second paragraph has been added.

This commit doesn't solve all issues in this setup. For example, cc.has_link_argument('-subsystem:windows,6.1')) won't work because that option contains a comma and can't be passed with -Wl,. I would like to leave it for now.

P.S. When quoting "Command line: XXXX" etc. as snippets from a logfile, the 80-columns convention doesn't apply (actually, the convention itself says that this is an exception), just enclose it in triple-backticks and carry on. :)

Unwrapped now. I don't write commit message as Markdown, as I work with command-line Git which displays plaintext.

[lhmouse]

Do those errors about macos-clang matter? I don't see these options in Meson source, and don't think these are caused by this commit:

[1/4] clang++ -ITestApplication.p -I. '-I../test cases/objcpp/3 objfw' -I/opt/homebrew/Cellar/objfw/1.2.3/include -I/opt/homebrew/include -fdiagnostics-color=always -Wall -Winvalid-pch -O0 -g -fexceptions -fobjc-exceptions -funwind-tables -fconstant-string-class=OFConstantString -Xclang -fno-constant-cfstrings -Xclang -fno-constant-nsnumber-literals -Xclang -fno-constant-nsarray-literals -Xclang -fno-constant-nsdictionary-literals -Xclang -fblocks -MD -MQ TestApplication.p/TestApplication.mm.o -MF TestApplication.p/TestApplication.mm.o.d -o TestApplication.p/TestApplication.mm.o -c '../test cases/objcpp/3 objfw/TestApplication.mm'
FAILED: TestApplication.p/TestApplication.mm.o 
clang++ -ITestApplication.p -I. '-I../test cases/objcpp/3 objfw' -I/opt/homebrew/Cellar/objfw/1.2.3/include -I/opt/homebrew/include -fdiagnostics-color=always -Wall -Winvalid-pch -O0 -g -fexceptions -fobjc-exceptions -funwind-tables -fconstant-string-class=OFConstantString -Xclang -fno-constant-cfstrings -Xclang -fno-constant-nsnumber-literals -Xclang -fno-constant-nsarray-literals -Xclang -fno-constant-nsdictionary-literals -Xclang -fblocks -MD -MQ TestApplication.p/TestApplication.mm.o -MF TestApplication.p/TestApplication.mm.o.d -o TestApplication.p/TestApplication.mm.o -c '../test cases/objcpp/3 objfw/TestApplication.mm'
error: unknown argument: '-fno-constant-nsnumber-literals'
error: unknown argument: '-fno-constant-nsarray-literals'
error: unknown argument: '-fno-constant-nsdictionary-literals'

[eli-schwartz]

If you can't see any way for your PR to have produced the error, it's usually worth looking to see whether the same error occurs on git master -- in this case, they do, so it's a known problem. :)

See e.g. Homebrew/homebrew-core#201295 (comment)

[lhmouse]

If you can't see any way for your PR to have produced the error, it's usually worth looking to see whether the same error occurs on git master -- in this case, they do, so it's a known problem. :)

See e.g. Homebrew/homebrew-core#201295 (comment)

OK fair enough.