CMake Linker failure under Arch Linux x64 with newest Emscripten #23944
Comments
|
P.S. the error persists even with |
|
I think this is an issue with the emscripten is being packaged on your system. What distro are you using? How is it setting the config file? How is it setting the cache directory? Did this used to work in the past (i.e. is this a regression)? |
|
The dirctory being passed the linker is I do notice that the If you re-run just the link command does it generate any output? (i.e. |
|
Ah wait.. I see the problem.. you seem to be passing |
Arch Linux x64
I have no clue, how can I figure that out?
Yes -- everything worked fine with Emscripten 3.1.72-1.
Yes, same error:
Nope, I am not passing those anywhere. If I search for them in the entire repository, I can only find them in |
So it looks like the debug libraries were somehow detected and cached, but then the release libraries are actually being using. Is you clear out the cache and re-run does the same thing happen again? With emscripten the names of those libraries will be different in debug and release configurations. |
Even after completely nuking the build folder and |
|
I guess we need to figure out what Can you perhaps share the full cmake command your ran and then the full make/ninja command you ran order to get that failure? |
|
Can you see if |
Could you try to bisect to find out where this broke: https://emscripten.org/docs/contributing/developers_guide.html#bisecting It does seem like #23537 would be the most likely cultprit but you say that adding |
From here: "Implicit link libraries are those that the compiler (not CMake) itself implicitly links. They are detected by CMake and stored in the variable; the variable is not meant to be modified."
Relevant presets: The ninja command was
None of my CMake files use that explicitly anywhere. |
I nuked the build and And it worked! So there must be something in both the cache and build folder that causes the issue. |
|
It seems that However for most projects that doesn't seem to be a problem. I can't seem to figure out why your project uses this value but non of our test cmake projects do. |
Is there anything I can try to narrow down the issue? I'll try reproducing with a smaller part of the project, but it's not trivial... |
|
I tried simple project and they don't have this issue, so there must be something interesting/special that your project is doing here that triggers to usage of |
Do you have a link to that project? If I compile it, I can at least rule out my environment as being the culprit. |
|
I just used one of our simple test projects: I then verified the And that they are not added to the link command: |
|
@sbc100: I managed to add a few things from my project to cmake_minimum_required(VERSION 3.16)
project(helloworld)
file(
DOWNLOAD
https://github.com/cpm-cmake/CPM.cmake/releases/download/v0.38.3/CPM.cmake
${CMAKE_CURRENT_BINARY_DIR}/cmake/CPM.cmake
EXPECTED_HASH SHA256=cc155ce02e7945e7b8967ddfaff0b050e958a723ef7aad3766d368940cb15494
)
include(${CMAKE_CURRENT_BINARY_DIR}/cmake/CPM.cmake)
CPMAddPackage(
NAME ogg
GITHUB_REPOSITORY xiph/ogg
GIT_TAG v1.3.5
SYSTEM TRUE
)
add_executable(helloworld main.cpp)
set_target_properties(helloworld PROPERTIES SUFFIX ".html")
target_link_options(helloworld PRIVATE -flto)
target_link_libraries(helloworld PRIVATE ogg)Note that commenting out |
|
Thanks, I was able to reproduce now. I'm trying to reduce it now. |
|
Here I the current command I'm using to reproduce: We can tell its broken because Strangely I remove |
Version of emscripten/emsdk:
Building and linking my VRSFML project under Arch Linux x64 works well with Emscripten 3.1.72-1, but linking fails under Emscripten 4.x with the following errors:
These are the CMake variables I use to build:
And this is the full output of the linking step which fails:
Searching for one of those libs via
locatereports:Is this a misconfiguration issue on my side, or is it a regression somewhere in Emscripten or in its CMake modules?
I am not sure how to debug any further.
The text was updated successfully, but these errors were encountered: