Depecrated --llvm-lto used in Emscripten upstream backend

[pezcode]

The Emscripten upstream backend uses the standard -flto option and emits a warning when --llvm-lto is used.

emcc:WARNING: --llvm-lto ignored when using llvm backend

One way to check whether the fastcomp backend is being used is to check for Clang 6.0.1 or older. Fastcomp stopped being supported with Emscripten > 1.40.1 which has that version. Upstream as old as 1.38.33 (oldest version I could get from emsdk) uses Clang 9.

However, the following doesn't work because the toolchain file doesn't have access the compiler version (CMAKE_CXX_COMPILER_VERSION is only detected by CMake afterwards):

if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 7.0)
    set(CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "-O3 --llvm-lto 1")
else()
    set(CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "-O3 -flto")
endif()

I fixed it with a

string(REPLACE "--llvm-lto 1" "-flto" CMAKE_EXE_LINKER_FLAGS_RELEASE ${CMAKE_EXE_LINKER_FLAGS_RELEASE})

in my code but the correct flag in the toolchain depending on the backend would be nicer.

[mosra]

Oh, so that was the leftover TODO i forgot to fix.

the following doesn't work because the toolchain file doesn't have access the compiler version

Wouldn't the Platform file be able to do that? There you probably wouldn't fill the *_INIT variables anymor, but directly the actual CMAKE_EXE_LINKER_FLAGS_RELEASE (or at least I hope the distinction was like that).

Upstream as old as 1.38.33 (oldest version I could get from emsdk) uses Clang 9.

Err... you mean 6? On Travis I'm deliberately using a macOS image with outdated homebrew ("chaotic evil" backwards compatibility checks, heh) and there it reports 6.0.1 for 1.8.44: https://travis-ci.com/github/mosra/corrade/jobs/428039848#L443-L445

But anyway, that matches my experience (I didn't have the --llvm-lto warning with 1.38.38, only started getting it after upgrading to 1.39.18 in June).

Besides checking compiler version, wasn't there some option that switched between the two? Or I misremember and you have to literally grab a different build?

[pezcode]

the following doesn't work because the toolchain file doesn't have access the compiler version

Wouldn't the Platform file be able to do that? There you probably wouldn't fill the *_INIT variables anymor, but directly the actual CMAKE_EXE_LINKER_FLAGS_RELEASE (or at least I hope the distinction was like that).

How does that file tie into CMake? Not really finding much info on Google. Does CMake call whatever ${CMAKE_SYSTEM_NAME}.cmake it can find in ${CMAKE_MODULE_PATH}?

Upstream as old as 1.38.33 (oldest version I could get from emsdk) uses Clang 9.

Err... you mean 6? On Travis I'm deliberately using a macOS image with outdated homebrew ("chaotic evil" backwards compatibility checks, heh) and there it reports 6.0.1 for 1.8.44: https://travis-ci.com/github/mosra/corrade/jobs/428039848#L443-L445

But anyway, that matches my experience (I didn't have the --llvm-lto warning with 1.38.38, only started getting it after upgrading to 1.39.18 in June).

Besides checking compiler version, wasn't there some option that switched between the two? Or I misremember and you have to literally grab a different build?

You need to install and activate fastcomp/upstream with emsdk, it's not a compiler option. Since 1.39 it defaults to upstream if you do emsdk install latest. Version 1.8.44 doesn't even have upstream.

Try emsdk install 1.38.33-fastcomp && emsdk activate 1.38.33-fastcomp and you should see 6.0.1, 1.38.33-upstream should report Clang 9.

[mosra]

How does that file tie into CMake?

Interesting, heh. All relevant info seems to be gone now, it was only in the old wiki (expand): https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/CrossCompiling#setting-up-the-system-and-toolchain

You need to install and activate fastcomp/upstream with emsdk

Ah. I'm using ArchLinux packages (or Homebrew), so I guess ... it just uses the default in either case, so < 1.39 was fastcomp, 1.39 and newer is upstream.

[mosra]

Fixed with #14 and b25ca89. "Thanks" to the three-year delay I didn't need to bother with fastcomp compatibility anymore.