LLVM 21 seemingly assumes that `strlen` is present even if libc is not linked

[alexrp]

I haven't created an isolated repro for this yet, but here are the symptoms:

test-standalone
└─ standalone_test_cases
   └─ standalone_test_cases.windows_resources
      └─ compile exe zig_resource_test Debug x86_64-windows-gnu 1 errors
error: ld.lld: undefined symbol: strlen
    note: referenced by resinator
    note:               /home/alexrp/.cache/zig/o/5a55db84c093a6181e460adf5c02418a/resinator_zcu.o:(zig.LibCInstallation.findNative)
    note: referenced by resinator
    note:               /home/alexrp/.cache/zig/o/5a55db84c093a6181e460adf5c02418a/resinator_zcu.o:(zig.LibCInstallation.findNative)
error: the following command failed with 1 compilation errors:
/home/alexrp/Source/ziglang/zig-llvm21/zig-out/bin/zig build-exe -rcflags /c65001 /I .zig-cache/o/aef5fcc6a94a711acf1fd5aefc9a8b35 -- /home/alexrp/Source/ziglang/zig-llvm21/test/standalone/windows_resources/res/zig.rc -ODebug -target x86_64-windows-gnu -mcpu baseline -Mroot=/home/alexrp/Source/ziglang/zig-llvm21/test/standalone/windows_resources/main.zig --cache-dir .zig-cache --global-cache-dir /home/alexrp/.cache/zig --name zig_resource_test -L /opt/llvm-21/lib -I /opt/llvm-21/include --zig-lib-dir lib/ --listen=-
test-standalone
└─ standalone_test_cases
   └─ standalone_test_cases.zerolength_check
      └─ run test
         └─ compile test ReleaseSmall wasm32-wasi 1 errors
error: wasm-ld: .zig-cache/o/f63cce3ea1b5c099048787fe888c88f2/test_zcu.o: undefined symbol: strlen
error: the following command failed with 1 compilation errors:
/home/alexrp/Source/ziglang/zig-llvm21/zig-out/bin/zig test -OReleaseSmall -target wasm32-wasi -mcpu baseline+bulk_memory -Mroot=/home/alexrp/Source/ziglang/zig-llvm21/test/standalone/zerolength_check/src/main.zig --cache-dir .zig-cache --global-cache-dir /home/alexrp/.cache/zig --name test -L /opt/llvm-21/lib -I /opt/llvm-21/include --zig-lib-dir lib/ --listen=-

It seems like LLVM is now assuming that strlen is present just based on the target triple? Note that we are not linking libc in these test cases.

cc @arsenm this seems like it could potentially be related to your recent libcall work?

[arsenm]

strlen currently isn't tracked in RuntimeLibcalls so nothing I did recently should have changed this

[alexrp]

strlen currently isn't tracked in RuntimeLibcalls so nothing I did recently should have changed this

Fair; thanks for confirming.

[nikic]

It seems like LLVM is now assuming that strlen is present just based on the target triple? Note that we are not linking libc in these test cases.

LLVM always defaults to the triple-implied available library calls (which, for a gnu triple, would be glibc libcalls). If you want to have a freestanding (*) build you need to use the "no-builtins" attribute or call disableAllFunctions() on TargetLibraryInfo.

I don't expect that anything in LLVM 21 has changed in this regard, apart from loop idiom recognization support for strlen in particular being added.

(*) Apart from the always required symbols from https://clang.llvm.org/docs/UsersManual.html#freestanding-builds.

[alexrp]

I don't expect that anything in LLVM 21 has changed in this regard, apart from loop idiom recognization support for strlen in particular being added.

Oh, I hadn't noticed that change. I suspect you're right.

LLVM always defaults to the triple-implied available library calls (which, for a gnu triple, would be glibc libcalls). If you want to have a freestanding (*) build you need to use the "no-builtins" attribute or call disableAllFunctions() on TargetLibraryInfo.

I'm guessing this would affect other libc functions like memcpy too, which we do provide in our compiler-rt (with weak linkage)... presumably for exactly this situation, now that I think about it... so we should probably just provide strlen now, too.

So indeed no LLVM issue here, I think.