-s USE_SDL=2 in compile doesn't choose correct header files any longer

[terop2]

trafficstars

It used to work ok, but with newest emscripten, the -s USE_SDL=2 doesnt any longer choose sdl2 version headers. Instead I get sdl1 version headers and thus Event structure writes are overwriting memory that they shouldnt do.

[terop2]

either that or SDL_PollEvent and Event structures are not in sync...

[terop2]

(I've started to use -flto, so its possible that causes the problem)

[terop2]

I got this kind of message from my code: LOW::SDL_PollEvent write outside of Event struct (maybe you're missing -s USE_SDL=2 in compiling)

[sbc100]

I don't think the "maybe you're missing -s USE_SDL=2 in compiling" is coming from emscripten itself. I don't think we have ever had such an error message. Can't you tell where that error is coming from?

Can you include the exact include statement that is failing?

[terop2]

Its this kind of test case in my code: struct SDL_EVENT_HACK { SDL_Event e; unsigned int cc; // HACK BECAUSE OF SDL EVENT UNION IS HANDLED BADLY IN EMSCRIOPTEN... EMSCRIPTEN WRITES ONE BYTE OUTSIDE OF SDL_Event structure. };

if (!event) { std::cout << "LOW::SDL_PollEvent called with null pointer" << std::endl; return 0; }
//SDL_Event e;
SDL_EVENT_HACK h;
  h.cc=0x55555555;
SDL_Event &e = h.e;
int val = ::SDL_PollEvent(&e);
if (h.cc!=0x55555555) { static bool firsttime=true; if (firsttime) { std::cout << "LOW::SDL_PollEvent write outside of Event struct (maybe you're missing -s USE_SDL=2 in compiling)" << std::endl; firsttime=false; }  }

[terop2]

we had that case failing earlier, but it was fixed with -s USE_SDL=2 to compile. that was supposed to choose sdl2 headers instead of sdl1 headers.

[sbc100]

With SDL my understanding is that you can do something like #include <SDL.h> , which is somewhat ambiguous, or you can do #include <SDL/SDL.h> or #include <SDL2/SDL.h> which are more explicit.

Do you know if you are doing the former of the later?

IIUC, even if you do #include <SDL.h> it should do the right thing based on if you use -sUSE_SDL=1 vs -sUSE_SDL2.

For example if you run emcc -sUSE_SDL=2 you should see something like this as your include path:

#include <...> search starts here:
 /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/SDL2
 /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/compat
 /usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/19/include
 /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include

Note that /.../sysroot/include/SDL2 comes first.

However if I run the same command with -sUSE_SDL=1 I get:

#include <...> search starts here:
 /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/SDL
 /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/compat
 /usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/19/include
 /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include

Note that the first entry here is for SDL1 and not SDL2.

[terop2]

I was doing #include <SDL.h>, changed it to #include <SDL2/SDL.h> and 2 other places with similar thing, and it fixed the issue.

[terop2]

I get suspicious warnings in the compilation: clang++: warning: argument unused during compilation: '-isystem /home/terop/cvs/emscripten/emsdk/upstream/emscripten/cache/sysroot/include/freetype2' [-Wunused-command-line-argument] lang++: warning: argument unused during compilation: '-isystem /home/terop/cvs/emscripten/emsdk/upstream/emscripten/cache/sysroot/include/SDL2' [-Wunused-command-line-argument]

[sbc100]

I get suspicious warnings in the compilation: clang++: warning: argument unused during compilation: '-isystem /home/terop/cvs/emscripten/emsdk/upstream/emscripten/cache/sysroot/include/freetype2' [-Wunused-command-line-argument] lang++: warning: argument unused during compilation: '-isystem /home/terop/cvs/emscripten/emsdk/upstream/emscripten/cache/sysroot/include/SDL2' [-Wunused-command-line-argument]

That seems odd.. -isystem should certainly be "used" during compilation. Can you share the full command line that generates that warning?