Fix LTO build

[alexcrichton]

• Don't use LTO for startup objects
• Put startup objects in the normal sysroot without LTO
• Pass -flto in linker flags
• Disable a test that fails with LTO enabled (unsure why)

[alexcrichton]

This was discovered as part of WebAssembly/wasi-sdk#584 where the wasm-tools command run on startup objects failed because the startup objects weren't actually wasm, they're bitcode. I don't believe enabling LTO in this repository has ever worked for running tests, only for building. This attempts to get everything working. I did a bit of digging to figure out what's going wrong in the failing test, but in the end I have no idea why. It's probably some strict aliasing thing or something like that, so I've just disabled it for now.

[yamt]

This was discovered as part of WebAssembly/wasi-sdk#584 where the wasm-tools command run on startup objects failed because the startup objects weren't actually wasm, they're bitcode. I don't believe enabling LTO in this repository has ever worked for running tests, only for building. This attempts to get everything working. I did a bit of digging to figure out what's going wrong in the failing test, but in the end I have no idea why. It's probably some strict aliasing thing or something like that, so I've just disabled it for now.

is this something specific to p2/p3?

[yamt]

can you add a link to a bug report?

[alexcrichton]

I don't have a bug report to link to. This repository does not control the source of this test, nor does this repository have WASI-specific source for insque and other functions. (I barely know what those functions are). If you'd like to open an issue I'd be happy to link it here.

[yamt]

Don't use LTO for startup objects

why?

Put startup objects in the normal sysroot without LTO

why?

Pass -flto in linker flags

this makes sense.

[alexcrichton]

Yes, startup objects are per-target. LTO is diasbles so the wasm-tools processing works. They're put in the normal sysroot because otherwise clang-19 locally didn't seem to find them.

[yamt]

Yes, startup objects are per-target. LTO is diasbles so the wasm-tools processing works.

can you limit the fix to p2/p3 then?

They're put in the normal sysroot because otherwise clang-19 locally didn't seem to find them.

clang-19 finds it for me.
did you have -flto specified when linking?

[yamt]

clang-19 finds it for me.

spacetanuki% /opt/wasi-sdk-25.0/bin/clang -v -flto --sysroot=${HOME}/git/wasi-libc/b/sysroot --target=wasm32-wasip1 a.c
clang version 19.1.5-wasi-sdk (https://github.com/llvm/llvm-project ab4b5a2db582958af1ee308a790cfdb42bd24720)
Target: wasm32-unknown-wasip1
Thread model: posix
InstalledDir: /Users/yamamoto/wasm/wasi-sdk-25.0-x86_64-macos/bin
 "/Users/yamamoto/wasm/wasi-sdk-25.0-x86_64-macos/bin/clang-19" -cc1 -triple wasm32-unknown-wasip1 -emit-llvm-bc -flto=full -flto-unit -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name a.c -mrelocation-model static -mframe-pointer=none -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu generic -fvisibility=hidden -debugger-tuning=gdb -fdebug-compilation-dir=/tmp/x -target-linker-version 1053.12 -v -fcoverage-compilation-dir=/tmp/x -resource-dir /Users/yamamoto/wasm/wasi-sdk-25.0-x86_64-macos/lib/clang/19 -isysroot /Users/yamamoto/git/wasi-libc/b/sysroot -internal-isystem /Users/yamamoto/wasm/wasi-sdk-25.0-x86_64-macos/lib/clang/19/include -internal-isystem /Users/yamamoto/git/wasi-libc/b/sysroot/include/wasm32-wasip1 -internal-isystem /Users/yamamoto/git/wasi-libc/b/sysroot/include -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -o /var/folders/74/hw1sphgx0lv63q6pq_n5grw00000gn/T/a-5eaf25.o -x c a.c
clang -cc1 version 19.1.5-wasi-sdk based upon LLVM 19.1.5-wasi-sdk default target wasm32-wasi
#include "..." search starts here:
#include <...> search starts here:
 /Users/yamamoto/wasm/wasi-sdk-25.0-x86_64-macos/lib/clang/19/include
 /Users/yamamoto/git/wasi-libc/b/sysroot/include/wasm32-wasip1
 /Users/yamamoto/git/wasi-libc/b/sysroot/include
End of search list.
 "/Users/yamamoto/wasm/wasi-sdk-25.0-x86_64-macos/bin/wasm-ld" -m wasm32 -L/Users/yamamoto/git/wasi-libc/b/sysroot/lib/wasm32-wasip1/llvm-lto/19.1.5-wasi-sdk -L/Users/yamamoto/git/wasi-libc/b/sysroot/lib/wasm32-wasip1 /Users/yamamoto/git/wasi-libc/b/sysroot/lib/wasm32-wasip1/llvm-lto/19.1.5-wasi-sdk/crt1-command.o /var/folders/74/hw1sphgx0lv63q6pq_n5grw00000gn/T/a-5eaf25.o -lc /Users/yamamoto/wasm/wasi-sdk-25.0-x86_64-macos/lib/clang/19/lib/wasip1/libclang_rt.builtins-wasm32.a -o a.out
spacetanuki% 

a.c is an empty file.
(it doesn't produce an appropriate error because of #485. but it's another story.)

[alexcrichton]

I'd prefer to keep the version-specific logic to an absolute minimum if necessary, but if you'd like to have a follow-up PR I can review that. If you're able to get clang-19 working as-is in CI without these changes I'm also happy to review that, but I needed these changes to get CI working.