[SDL2] [SDL3] Qestion about building with another libc #11528

blogdron · 2024-11-24T10:55:17Z

System Information

OS

dron@gnu:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux trixie/sid
Release:	n/a
Codename:	trixie
dron@gnu:~$

CMAKE

dron@gnu:~$ cmake --version
cmake version 3.31.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).
dron@gnu:~$

GCC

dron@gnu:~$ gcc --version
gcc (Debian 14.2.0-7) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

MUSL

dron@gnu:~$ musl-ldd --version
musl libc (x86_64)
Version 1.2.5
Dynamic Program Loader
Usage: musl-ldd [options] [--] pathname
dron@gnu:~$

Hello, Im make home experiments with building SDL for non glibc libc, for example musl but I have strange errors with building SDL2 and SDL3 under musl-gcc, includes collision? Im very bad understand cmake, maybe it stupid case but Im not found solution and do not understand where main problem. For start experiments I create Makefile

help:
	@echo "------------------------------------------------"
	@echo "all-------: get sdl2 + sld3, configure + build -"
	@echo "getsdl----: get sdl2 and sdl3                  -"
	@echo "sdl2------: configure and build sdl2           -"
	@echo "sdl3------: configure and build sdl3           -"
	@echo "clean-----: clear build dirs in sdl2 + sdl3    -"
	@echo "clear-----: clear all files                    -"
	@echo "------------------------------------------------"

getsdl:
	curl -o SDL2.zip -L --skip-existing https://github.com/libsdl-org/SDL/archive/refs/tags/release-2.30.9.zip
	curl -o SDL3.zip -L --skip-existing https://github.com/libsdl-org/SDL/archive/refs/tags/preview-3.1.6.zip
	unzip SDL2.zip
	unzip SDL3.zip
	mv SDL-preview-3.1.6  SDL3
	mv SDL-release-2.30.9 SDL2


sdl2:
	@echo "===============================SDL2================================="
	mkdir -p SDL2/build
	export CFLAGS='-std=c99' CC='musl-gcc' && cd SDL2/build && cmake .. -DCMAKE_BUILD_TYPE=Release
	export CFLAGS='-std=c99' CC='musl-gcc' && cd SDL2/build && cmake --build . --config Release

sdl3:
	@echo "===============================SDL3================================"
	mkdir -p SDL3/build
	export CFLAGS='-std=c99' CC='musl-gcc' && cd SDL3/build && cmake .. -DCMAKE_BUILD_TYPE=Release
	export CFLAGS='-std=c99' CC='musl-gcc' && cd SDL3/build && cmake --build . --config Release

clean:
	-$(RM) -rfd SDL2/build
	-$(RM) -rfd SDL2/build

clear:
	$(MAKE) clean
	$(RM) SDL2.zip
	$(RM) SDL3.zip

all:
	$(MAKE) getsdl
	$(MAKE) sdl2
	$(MAKE) sdl3

Now run this

make all

Main errors here (bottom in log)

[ 15%] Building C object CMakeFiles/SDL2main.dir/src/main/dummy/SDL_dummy_main.c.o
In file included from /home/dron/SDL2-MUSL/SDL2/build/include/SDL2/SDL_stdinc.h:37,
                 from /home/dron/SDL2-MUSL/SDL2/build/include/SDL2/SDL_assert.h:25,
                 from /home/dron/SDL2-MUSL/SDL2/src/main/dummy/../../SDL_internal.h:208,
                 from /home/dron/SDL2-MUSL/SDL2/src/main/dummy/SDL_dummy_main.c:4:
/usr/include/stdio.h:53:9: error: unknown type name ‘__gnuc_va_list’
   53 | typedef __gnuc_va_list va_list;
      |         ^~~~~~~~~~~~~~
/usr/include/stdio.h:53:24: error: conflicting types for ‘va_list’; have ‘int’
   53 | typedef __gnuc_va_list va_list;
      |                        ^~~~~~~
In file included from /usr/include/x86_64-linux-musl/stdarg.h:10,
                 from /usr/include/stdio.h:37:
/usr/include/x86_64-linux-musl/bits/alltypes.h:326:27: note: previous declaration of ‘va_list’ with type ‘va_list’ {aka ‘__va_list_tag[1]’}
  326 | typedef __builtin_va_list va_list;
      |                           ^~~~~~~
/usr/include/stdio.h:373:22: error: unknown type name ‘__gnuc_va_list’
  373 |                      __gnuc_va_list __arg) __nonnull ((1));
      |                      ^~~~~~~~~~~~~~
/usr/include/stdio.h:378:54: error: unknown type name ‘__gnuc_va_list’
  378 | extern int vprintf (const char *__restrict __format, __gnuc_va_list __arg);
      |                                                      ^~~~~~~~~~~~~~
/usr/include/stdio.h:381:22: error: unknown type name ‘__gnuc_va_list’
  381 |                      __gnuc_va_list __arg) __THROWNL;
      |                      ^~~~~~~~~~~~~~

These lines confuse me

In file included from /usr/include/x86_64-linux-musl/stdarg.h:10,
                 from /usr/include/stdio.h:37:

Im do not understand why used /usr/include/stdio.h instead /usr/include/x86_64-linux-musl/stdio.h Im no find in CMakeList.txt redifinition.
Musl create wrapper under gcc and use spec file for set system -isystem include path.

dron@gnu:~$ cat /usr/bin/musl-gcc 
#!/bin/sh
exec "${REALGCC:-x86_64-linux-gnu-gcc}" "$@" -specs "/usr/lib/x86_64-linux-musl/musl-gcc.specs"
dron@gnu:~$

Inside spec file have redifinition for system includes

/usr/lib/x86_64-linux-musl/musl-gcc.specs

...
*cpp_options:
-nostdinc -isystem /usr/include/x86_64-linux-musl -isystem include%s %(old_cpp_options)

*cc1:
%(cc1_cpu) -nostdinc -isystem /usr/include/x86_64-linux-musl -isystem include%s
...

And in my mind now compiler expect take all libc headers like stdlib.h from musl, not from system because behavior gcc as driver program is redeclarated, because used special spec file

https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Inside SDL source not contains __gnuc_va_list directly. This is not SDL problem. But maybe cmake or cmake configuration in SDL source tree drop musl spec file configuration?

I'd be glad if someone at least pointed out which way to look, I think I'm stupid, I can't figure out where exactly something is going wrong. At first glance, everything is correct, but :D

Thank for Any ideas 😊

Sorry if it is off-topic, maybe just close it

The text was updated successfully, but these errors were encountered:

madebr · 2024-11-24T11:11:08Z

With a verbose build, you can see what arguments are passed to $CC:

cmake --build . --config Release --verbose

SDL has system dependencies, for which it might need to do -I/usr/include.
You might need to build some/all dependencies with your musl toolchain, and install in a separate prefix directory.
In general, when targeting another platform or libc, it's best to write a dedicated CMake toolchain file. The one from Emscripten is a good example.

Sorry if it is off-topic, maybe just close it

Indeed. This issue is not sdl specific.

blogdron · 2024-11-24T11:17:18Z

@madebr Thanks for the useful information :)

madebr closed this as not planned Won't fix, can't repro, duplicate, stale Nov 24, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SDL2] [SDL3] Qestion about building with another libc #11528

[SDL2] [SDL3] Qestion about building with another libc #11528

[SDL2] [SDL3] Qestion about building with another libc #11528

[SDL2] [SDL3] Qestion about building with another libc #11528

Comments