CMake's FindPkgConfig may pollute linker path with system paths

[nthirtyone]

Overview

When CMake uses FindPkgConfig module it may use system pc files if they are available which may result in polluting include or library paths as by default CMake sets PKG_CONFIG_ALLOW_SYSTEM_LIBS.

Details

For example, raylib's CMake config uses pkg_check_modules to provide hints for find_path and find_library. Additionally, it sets INTERFACE_LINK_LIBRARIES of generated target to LDFLAGS listed by pkg-config. In case that native raylib version is installed it will add -L/usr/lib to linker flags resulting in wasm-ld trying to link native dynamic objects.

While some of the fault could be attributed to the behaviour of raylib's CMake config file, Emscripten could stop it from making this mistake simply by limiting the PKG_CONFIG_LIBDIR. In fact, emconfigure and emmake wrappers do that. However, that's not the case for emcmake.

Is there any particular reason for that?

Would it be feasible to wrap emcmake cmake in the building environment (or partial that contains PKG_CONFIG_* variables)?

Alternatively, cmake tool-chain file could be modified to contain following:

set(ENV{PKG_CONFIG_LIBDIR} "${EMSCRIPTEN_SYSROOT}/local/lib/pkgconfig:${EMSCRIPTEN_SYSROOT}/lib/pkgconfig")

Or something similar.

Side Notes

Please note that pkg-config paths resolution from CMake point of view in cross-compilation context can be confusing. Hence why the output of the example command may be such. In case you use .emscripten_cache/sysroot as installation prefix everything is straight-forward (well, except for #15576, which I hope to address soon in a next issue). However, when one tries to use a custom installation prefix they need to define both:

• CMAKE_FIND_ROOT_PATH - to make CMake find *.cmake files
• CMAKE_PREFIX_PATH - to make pkg-config find *.pc files

What I see here so far is that there is a very weird relationship between CMAKE_FIND_ROOT_PATH, CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH_MODE_*, find_*(), and FindPkgConfig. I don't think there is anything we can do to address that and perhaps it would be better to push it upstream to CMake.

Alternatively to CMAKE_PREFIX_PATH, assuming that cmake is run in environment provided by tools.building.get_building_env, EM_PKG_CONFIG_PATH environmental variable can be used.

Version of emscripten/emsdk

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.9-git (54675bac246e84ca024c182e477665d21fe2e2f7)
clang version 15.0.0 (/startdir/llvm-project faef447e72a5c63dfb12bb7b02d44c3c916d31cd)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /opt/emscripten-llvm/bin

Failing command line in full

$ emcmake cmake -B build .
configure: cmake -B build . -DCMAKE_TOOLCHAIN_FILE=/usr/lib/emscripten/cmake/Modules/Platform/Emscripten.cmake -DCMAKE_CROSSCOMPILING_EMULATOR=/usr/bin/node;--experimental-wasm-threads
-- Found raylib: /home/aki/src/raylib/build_web2/prefix/lib/libraylib.a (Required is at least version "3")
-- raylib_FOUND: TRUE
-- raylib_INCLUDE_DIRS: /home/aki/src/raylib/build_web2/prefix/include
-- raylib_LIBRARIES: /home/aki/src/raylib/build_web2/prefix/lib/libraylib.a
-- raylib_LDFLAGS: -L/usr/lib -lraylib -L/usr/lib -lglfw -lrt -lm -ldl -L/usr/lib -lX11 -lpthread -L/usr/lib -lxcb -L/usr/lib -lXau -lXdmcp
-- raylib_DEFINITIONS:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/aki/src/emscripten/build

Then when make is running:

[100%] Linking CXX executable emscripten_cpp_raylib.html
"/opt/emscripten-llvm/bin/wasm-ld" -o emscripten_cpp_raylib.wasm CMakeFiles/emscripten_cpp_raylib.dir/main.cpp.o /home/aki/src/raylib/build_web2/prefix/lib/libraylib.a -L/usr/lib /usr/lib/libraylib.so -L/usr/lib -L/usr/lib -L/usr/lib /usr/lib/libxcb.so -L/usr/lib /usr/lib/libXau.so /usr/lib/libXdmcp.so -L/home/aki/.emscripten_cache/sysroot/lib/wasm32-emscripten -lGL -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --export-if-defined=main --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__stdio_exit --export=emscripten_stack_get_base --export=emscripten_stack_get_end --export=emscripten_stack_set_limits --export=emscripten_stack_get_free --export=emscripten_stack_init --export=stackSave --export=stackRestore --export=stackAlloc --export=__wasm_call_ctors --export=__errno_location --export=malloc --export=free --export=__dl_seterr --export=emscripten_builtin_malloc --export=emscripten_builtin_free --export-table -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=16777216 --global-base=1024
wasm-ld: error: unknown file type: /usr/lib/libraylib.so
wasm-ld: error: unknown file type: /usr/lib/libxcb.so
wasm-ld: error: unknown file type: /usr/lib/libXau.so
wasm-ld: error: unknown file type: /usr/lib/libXdmcp.so
 em++: error: '/opt/emscripten-llvm/bin/wasm-ld -o emscripten_cpp_raylib.wasm CMakeFiles/emscripten_cpp_raylib.dir/main.cpp.o /home/aki/src/raylib/build_web2/prefix/lib/libraylib.a -L/usr/lib /usr/lib/libraylib.so -L/usr/lib -L/usr/lib -L/usr/lib /usr/lib/libxcb.so -L/usr/lib /usr/lib/libXau.so /usr/lib/libXdmcp.so -L/home/aki/.emscripten_cache/sysroot/lib/wasm32-emscripten -lGL -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --export-if-defined=main --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__stdio_exit --export=emscripten_stack_get_base --export=emscripten_stack_get_end --export=emscripten_stack_set_limits --export=emscripten_stack_get_free --export=emscripten_stack_init --export=stackSave --export=stackRestore --export=stackAlloc --export=__wasm_call_ctors --export=__errno_location --export=malloc --export=free --export=__dl_seterr --export=emscripten_builtin_malloc --export=emscripten_builtin_free --export-table -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=16777216 --global-base=1024' failed (returned 1)
make[2]: *** [CMakeFiles/emscripten_cpp_raylib.dir/build.make:101: emscripten_cpp_raylib.html] Error 1
make[1]: *** [CMakeFiles/Makefile2:139: CMakeFiles/emscripten_cpp_raylib.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

[sbc100]

The reason that we use tools.building.get_building_env for configure and make and not for cmake I think is that our cmake toolchain fail is supposed to be the way that the compiler (CC, etc) is setup whereas autoconf and make rely on the surrounding environment.

I think for PKG_CONFIG_LIBDIR the solution, as you suggest is probably to set PKG_CONFIG_LIBDIR in the toolchain file:

set(ENV{PKG_CONFIG_LIBDIR} "${EMSCRIPTEN_SYSROOT}/local/lib/pkgconfig:${EMSCRIPTEN_SYSROOT}/lib/pkgconfig")

In general, the toolchain file should do everything that tools.building.get_building_env does, but without relying on the environment. I see it as an alternative to get_building_env.

Would setting CMAKE_PREFIX_PATH avoid the need for PKG_CONFIG_LIBDIR? if so then lets set that instead.

[nthirtyone]

Would setting CMAKE_PREFIX_PATH avoid the need for PKG_CONFIG_LIBDIR? if so then lets set that instead.

No, CMAKE_PREFIX_PATH contributes to PKG_CONFIG_PATH. AFAIK, FindPkgConfig does not touch PKG_CONFIG_LIBDIR by itself at all.

In general, the toolchain file should do everything that tools.building.get_building_env does, but without relying on the environment. I see it as an alternative to get_building_env.

OK, I will draft changes to the toolchain in this case (hopefully more solid than that one-liner).