Project fails to build with CMake when DirectFB backend is enabled

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.12 Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2020-12-18 14:46:37 +0000, Simon Zeni wrote:

On Alpinelinux, where the DirectFB backend is enabled in the package itself (https://git.alpinelinux.org/aports/tree/community/sdl2/APKBUILD#n53), several CMake projects that uses SDL2's SDL2Targets.cmake will fail to build with the following error

In file included from /home/simon/dev/FNA3D/src/FNA3D_Driver_OpenGL.c:33: /usr/include/SDL2/SDL_syswm.h:80:10: fatal error: directfb.h: No such file or directory 80 | #include <directfb.h> | ^~~~~~~~~~~~ compilation terminated. make[2]: *** [CMakeFiles/FNA3D.dir/build.make:108: CMakeFiles/FNA3D.dir/src/FNA3D_Driver_OpenGL.c.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from /home/simon/dev/FNA3D/src/FNA3D_Driver_Vulkan.c:36: /usr/include/SDL2/SDL_syswm.h:80:10: fatal error: directfb.h: No such file or directory 80 | #include <directfb.h> | ^~~~~~~~~~~~ compilation terminated.

The build is successful if SDL2 is found through pkgconfig.

[madebr]

Using an alpine docker image I was able to build SDL2 with directfb support.

Start the container:

docker run -ti -v $PWD:/src:z alpine:edge /bin/sh

Run the following commands inside the container:

apk add cmake gcc g++ musl-dev ninja directfb-dev linux-headers
cmake -S /src -B /src/build_alpine -GNinja -DSDL_DIRECTFB=ON
# Verify the output contains: 
# --   SDL_DIRECTFB                (Wanted: ON): ON
# --   SDL_DIRECTFB_SHARED         (Wanted: ON): ON
cmake --build /src/build_alpine

It builds fine, with the following warnings:

/src/src/video/directfb/SDL_DirectFB_render.c: In function 'DirectFB_RunCommandQueue':
/src/src/video/directfb/SDL_DirectFB_render.c:928:35: warning: declaration of 'vertices' shadows a parameter [-Wshadow]
  928 |                         DFBVertex vertices[3];
      |                                   ^~~~~~~~
/src/src/video/directfb/SDL_DirectFB_render.c:721:81: note: shadowed declaration is here
  721 | DirectFB_RunCommandQueue(SDL_Renderer * renderer, SDL_RenderCommand *cmd, void *vertices, size_t vertsize)
      |    

/src/src/video/directfb/SDL_DirectFB_events.c: In function 'ProcessInputEvent':
/src/src/video/directfb/SDL_DirectFB_events.c:312:9: warning: variable 'kbd_idx' set but not used [-Wunused-but-set-variable]
  312 |     int kbd_idx;
      | 

[bl4ckb0ne]

That's my issue, SDL2 builds fine on Alpinelinux 1 . My is is building software with SDL2. Alpinelinux has the directfb.h header in /usr/include/directfb/ but SDL2 expects it in /usr/include, which leads to compilation errors.

I believe the SDL2Targets.cmake forgets to carry the include path for directfb, but it's unlikely to get fixed because the backend is deprecated. I managed to get around it by adding the include path to directfb directly in the project I'm building with pkg-config --cflags directfb

[madebr]

I noticed that sdl2.pc hardcodes the directfb include path. The sdl2.pc of alpine contains the following:

...
Requires:
Conflicts:
Libs: -L${libdir}  -pthread -lSDL2  
Libs.private: -lrt -lm  -Wl,--no-undefined -pthread -lSDL2 
Cflags: -I${includedir}/SDL2 -I/usr/include/directfb -D_REENTRANT -D_REENTRANT

The path of directfb is hardcoded in the .pc file. I will submit a patch shortly that will convert it into:

...
Requires:  directfb
Conflicts:
Libs: -L${libdir} -Wl,-rpath,${libdir} -Wl,--enable-new-dtags -lSDL2  
Libs.private: -lrt -lm  -pthread -lSDL2 
Cflags: -I${includedir}/SDL2  -D_REENTRANT

EDIT: Looking at it again, I think it is not correct as sdl2 loads directfb dynamically.

I think your issue is the SDL2::SDL2 and SDL2::SDL2-static targets not automatically adding the directfb include path?

[PureTryOut]

I've been experiencing this and compiled SDL2 2.23.2 to test the PR that was supposed to fix this, and in my testing it doesn't sadly, I'm also on Alpine Linux and using their packaging.

sdl2.pc currently has the following in 2.23.2:

# sdl pkg-config source file

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: sdl2
Description: Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.
Version: 2.23.2
Requires:
Conflicts:
Libs: -L${libdir}   -lSDL2 
Libs.private:  -lSDL2 -pthread  -lm -lrt
Cflags: -I${includedir} -I${includedir}/SDL2  -I/usr/include/directfb -D_REENTRANT -D_REENTRANT

[slouken]

I think it is correct to have the directfb include flags in the Cflags in sdl2.pc. (@madebr, we'll need to do the same for X11, since those headers are also included in SDL_syswm.h)

It seems like the problem here is that CMake isn't picking up those flags? Is that right?

[madebr]

It seems like the problem here is that CMake isn't picking up those flags? Is that right?

Yes, I misunderstood the issue and added the directfb flags only to the .pc file. https://github.com/libsdl-org/SDL/pull/6084 also looks for directfb in the generated sdl2-config.cmake/SDL2config.cmake files.

@PureTryOut Can you test https://github.com/libsdl-org/SDL/pull/6084?

[PureTryOut]

Yup, that fixes the issue! Is there any chance it can make the cut for 2.24.0?

[icculus]

Is there any chance it can make the cut for 2.24.0?

I don't think so, 2.24 is shipping as soon as today, and it's a non-trivial patch. But it can go in revision control as soon as the release ships!

[madebr]

I think it is correct to have the directfb include flags in the Cflags in sdl2.pc. (@madebr, we'll need to do the same for X11, since those headers are also included in SDL_syswm.h)

I'm working on CMake with X11 right now.

Does anyone know of a Linux distribution (preferably providing a Docker container) which has the libX11 development headers/libraries available in a non-standard location? By non-standard, I mean not in /usr/include/X11. I would like to test my changes.

[slouken]

Does anyone know of a Linux distribution (preferably providing a Docker container) which has the libX11 development headers/libraries available in a non-standard location? By non-standard, I mean not in /usr/include/X11. I would like to test my changes.

I just installed OpenBSD, and it has X11 headers in /usr/X11R6/include