Doubts while using -s USE_SDL=2

[anutosh491]

Hi,

I am trying to run the "smallpt: Global Illumination in 99 lines of C++" by Kevin Beason https://www.kevinbeason.com/smallpt/ in xeus-cpp-lite

I think I might have shared the link for running C++ completely in the browser through Jupyterlite previously https://compiler-research.org/xeus-cpp/lab/index.html

Context :

1. As we are heavy users of emscripten and emscripten has good support for SDL, we thought of running the above classic example in our notebook.
2. Here's the PR adding the notebook Add smallpt example notebook running through xeus-cpp-lite compiler-research/xeus-cpp#299
3. So now you should be able to see the example notebook in the file system (smallpt.ipynb) ... when you open the link above

[anutosh491]

Problem :

While building locally through macos, we see this

And everything works fine and we get the output as expected

But while building on linux, we see this

Importantly

1. Our github deployment is built on top of ubuntu, so we're having issues with people trying out the notebook
2. Nothing really looks wrong at a first glance

i) in the ci, you can the sdl2 port being put to use ( https://github.com/compiler-research/xeus-cpp/actions/runs/15154294457/job/42606024480#step:5:139 )

ii) The cmakelists.txt done nothing different for macos or ubuntu (https://github.com/compiler-research/xeus-cpp/blob/main/CMakeLists.txt#L439)

iii) As a hack around on linux machine, while building locally we see that it might just a timing issue.
Basically just making sure the SDL2 port is available before building xeus-cpp

# The test file is empty
em++ test_file.cpp -sUSE_SDL=2

[anutosh491]

I fail to understand what's going wrong here.
cc @sbc100 could you please help us out here ?

[MarkCallow]

I am seeing the same issue in a different guise. We use the docker image and cmake. During the cmake configure I get

CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find SDL2 (missing: SDL2_LIBRARY SDL2_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindSDL2.cmake:206 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  tests/loadtests/CMakeLists.txt:35 (find_package)

Cause is the same as @anutosh491's problem, the SDL headers and lib are not installed.

This problem started in either 4.0.8 or 4.0.9. 4.0.7 worked fine. I tried changing -s USE_SDL=2 to --use-port=sdl2 but the problem still happens.

I have not yet managed to find the release notes to see if there is any mention there of a change to how to use SDL.

[MarkCallow]

@anutosh491 please edit the issue description to say that SDL2 is missing.

[MarkCallow]

I have not yet managed to find the release notes to see if there is any mention there of a change to how to use SDL.

I found them, changelog.md. There is nothing in the changes for either 4.0.8 or 4.0.9 to indicate any needed changes when using SDL.

[anutosh491]

Hey @MarkCallow I forgot to mention a very important point above. Which is that I am using emscripten 3.1.73

And to be fair, I don't know if "SDL2 is missing" is the issue !

Cause as I said, If I do the same build on macos (using the same flag) I can access SDL2 but on linux what I see it, I need to put the flag to use before the build (not sure how this matters or activates relevant ports) but once i do this

# The test file is empty
em++ test_file.cpp -sUSE_SDL=2

I can get it working locally !

So for now my problems ends up being more about how do I get this through my deployment

1. We're building xeus-cpp with the flag and we're using ubuntu in the ci
2. So directly putting it to use doesn't work out for me.

[mcbarton]

It doesn't work for a MacOS Github runner too. See compiler-research/xeus-cpp#301 (comment)

[anutosh491]

Okay which means this works locally but when we try using this through the Ci something goes off ?

[mcbarton]

Okay which means this works locally but when we try using this through the Ci something goes off ?

My guess is that something exists on your local machine, but not on the Github runners. If you look here https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md you can see what is installed on the Github runner for Ubuntu.

[MarkCallow]

Okay which means this works locally but when we try using this through the Ci something goes off ?

For me it is broken both locally (macOS) and in GitHub CI (Linux runner). Both cases use the Docker latest image.

[anutosh491]

For me it is broken both locally (macOS) and in GitHub CI (Linux runner). Both cases use the Docker latest image.

Ohh so you tried building xeus-cpp-lite as per what the docs said and tried including SDL2/SDL.h ?

My guess is that something exists on your local machine, but not on the Github runners.

Can try a fresh build soon but I am quite positive this shouldn't be the error !

[MarkCallow]

My guess is that something exists on your local machine, but not on the Github runners.

The Github runners will likely be using the latest version of Emscripten while you may have an older version locally. As I said building with SDL2 was working fine in 4.0.7 but is broken in 4.0.9.

[MarkCallow]

Ohh so you tried building xeus-cpp-lite as per what the docs said and tried including SDL2/SDL.h ?

No. I am building my own project which uses SDL2. It worked for years until 4.0.9 came along.

[anutosh491]

Can try a fresh build soon but I am quite positive this shouldn't be the error !

This is the weirdest of all issues I have come across in a while

1. If we start fresh (using main and fresh envs), do the build and try running the example (it can't fetch SDL2/SDL.h) and fails

2. get rid of the build, just use the sdl2 port again with an empty file
   (This should obviously not be required, as we already have USE_SDL=2 in our cmake file)

(xeus-cpp-wasm-build) anutosh491@Anutoshs-MacBook-Air xeus-cpp % em++ test-file.cpp -sUSE_SDL=2
cache:INFO: generating port: sysroot/lib/wasm32-emscripten/libSDL2.a... (this will be cached in "/Users/anutosh491/micromamba/envs/xeus-cpp-wasm-build/opt/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libSDL2.a" for subsequent builds)
system_libs:INFO: compiled 118 inputs in 9.19s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libstubs-debug.a... (this will be cached in "/Users/anutosh491/micromamba/envs/xeus-cpp-wasm-build/opt/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libstubs-debug.a" for subsequent builds)
system_libs:INFO: compiled 2 inputs in 0.19s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc-debug.a... (this will be cached in "/Users/anutosh491/micromamba/envs/xeus-cpp-wasm-build/opt/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libc-debug.a" for subsequent builds)
system_libs:INFO: compiled 1037 inputs in 12.10s
cache:INFO:  - ok
cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libc++abi-debug-noexcept.a... (this will be cached in "/Users/anutosh491/micromamba/envs/xeus-cpp-wasm-build/opt/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++abi-debug-noexcept.a" for subsequent builds)
system_libs:INFO: compiled 16 inputs in 2.38s
cache:INFO:  - ok
cache:INFO: generating system asset: symbol_lists/02a267d693e85ca2100c1e68bd297051174b02c2.json... (this will be cached in "/Users/anutosh491/micromamba/envs/xeus-cpp-wasm-build/opt/emsdk/upstream/emscripten/cache/symbol_lists/02a267d693e85ca2100c1e68bd297051174b02c2.json" for subsequent builds)
cache:INFO:  - ok

3. I don't know how this concretizes the sdl2 port but running the notebook after this work fine

for any macos/ubuntu anything.

We are obviously generating the port in our CI too (https://github.com/compiler-research/xeus-cpp/actions/runs/15187142069/job/42710203495#step:5:140)

[sbc100]

I am seeing the same issue in a different guise. We use the docker image and cmake. During the cmake configure I get

CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find SDL2 (missing: SDL2_LIBRARY SDL2_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindSDL2.cmake:206 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  tests/loadtests/CMakeLists.txt:35 (find_package)

Cause is the same as @anutosh491's problem, the SDL headers and lib are not installed.

This problem started in either 4.0.8 or 4.0.9. 4.0.7 worked fine. I tried changing -s USE_SDL=2 to --use-port=sdl2 but the problem still happens.

I have not yet managed to find the release notes to see if there is any mention there of a change to how to use SDL.

Ah yes, this looks like it was likely caused by #24306 which was released in 4.0.9.

I certainly should have mentioned that in the changelog.

Basically SDL2 (and SDL3) are installed on demand either by running an emcc command with -sUSE_SDL=2 or -sUSE_SDL=3, or by using ./embuilder build sdl2 or ./embuilder build sdl3.

The sdl2-config.cmake file, which cmake uses to find the SDL2 installation is now created as part of that install phase. Prior to #24306 this would work because we would install sdl2-config.cmake all the time, even if SDL2 itself was not yet installed.

This upshort is that cmake will not longer detect the presence of SDL2 until you take some step to install it. Although this is slighly less convenient I think it makes sense overall that cmake only report libraries that are actually installed.

I will add this to changelog.

[anutosh491]

Well my issue turns out to be on emsdk 3.1.73 so I am not sure we both had the same issues 😕

[sbc100]

Yup sounds like a different issue then.

[sbc100]

I fail to understand what's going wrong here. cc @sbc100 could you please help us out here ?

When you run clang in the notebook I suppose that you not actually running emcc, but clang directly?

If so, then you cannot use the -sUSE_SDL=2 flag there to automatically have SDL2 installed when you compile, but you would need to pre-install into the sysroot directory using either ./embuilder build sdl2 or emcc -sUSE_SDL2 dummy.c.

[sbc100]

Updated ChangeLog: #24395

[anutosh491]

Hey @sbc100, thanks for this comment #24394 (comment)

I could find this as a workaround #24394 (comment)

Do you think the workaround works due to the what you mentioned above (not having automatic access to SDL2 ?)

[sbc100]

I think the issue of cmake not detecting SDL2 is completely separate and unrelated.

For your issue, where you are running clang directly, (and not via emcc) it is up to you to make sure that SDL2 is installed in sysroot / filesystem before running clang.