Probe can't find /usr/include/SDL2/SDL_ttf.h

[0cjs]

On 5506d39a2, the current head of master as I write this, configure on my Debian 9 system fails to find only one library, SDL2_ttf. The relevant lines in probe.log appear to be:

compiler command: g++ -c derived/x86_64-linux-opt/config/SDL2_TTF.cc -o derived/x86_64-linux-opt/config/SDL2_TTF.o -m64
derived/x86_64-linux-opt/config/SDL2_TTF.cc:1:21: fatal error: SDL_ttf.h: No such file or directory
 #include <SDL_ttf.h>
                     ^
compilation terminated.
return code from compiler: 1
SDL2_TTF: Missing header
SDL2_TTF: Cannot test linking because compile failed

I have the header file, as installed by the Debian libsdl-ttf2.0-dev package, but it's in /usr/include/SDL/SDL_ttf.h.

My feeling is that the build system should be able automatically to find this, but I'm open to workarounds as well. I didn't notice any obvious documentation (in the top-level dir or the doc/ subdir) on how to configure the build to add additional include paths.

[mthuurne]

libsdl-ttf2.0-dev is SDL_ttf for SDL 1.2. The master branch uses SDL2 instead, for which you need to install libsdl2-ttf-dev.

[0cjs]

Oh boy. Nothing like having 1.2 and 2.0 versions of things where the 2.0 has l2 as part of the name. I'd better put on stronger reading glasses for this one.

However, in this case the error was in what I pasted into my post above. For libsdl2-ttf-dev (which I do have installed) the include file is also /usr/include/SDL2/SDL_ttf.h:

$ apt-file search SDL_ttf.h
cmake-doc: /usr/share/doc/cmake-data/html/module/FindSDL_ttf.html
libsdl-ttf2.0-dev: /usr/include/SDL/SDL_ttf.h
libsdl2-ttf-dev: /usr/include/SDL2/SDL_ttf.h
$ grep 'define SDL_TTF_M.*_VERSION' /usr/include/SDL2/SDL_ttf.h
#define SDL_TTF_MAJOR_VERSION   2
#define SDL_TTF_MINOR_VERSION   0

[MBilderbeek]

Did you try to run 'make probe' to redo the probe explicitly?

[mthuurne]

Can you check derived/x86_64-linux-opt/config/probed_defs.mk for the flags the probe determined for SDL2? For example, on my system it contains these lines:

SDL2_TTF_CFLAGS:=-I/usr/include/SDL2 -D_REENTRANT -I/usr/include/freetype2
SDL2_TTF_LDFLAGS:=-lSDL2_ttf -L/usr/lib64 -lSDL2

[MBilderbeek]

I'm on Debian testing and I get:

SDL2_TTF_CFLAGS:=-I/usr/include/SDL2 -D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng16
SDL2_TTF_LDFLAGS:=-lSDL2_ttf -lSDL2

[0cjs]

Did you try to run 'make probe' to redo the probe explicitly?

I ran ./configure, which after a few checks to find a preferred Make binary does:

# Invoke actual probe.
$MAKE -f build/main.mk probe

[0cjs]

Can you check derived/x86_64-linux-opt/config/probed_defs.mk for the flags the probe determined for SDL2?

It contains the following. Note that this is different from @MBilderbeek's Debian system above, but he doesn't mention whether he's running Debian 9 as I am or some other version of Debian.

SDL2_TTF_CFLAGS:=                                                                   
SDL2_TTF_LDFLAGS:=-lSDL2_ttf -L/usr/lib/x86_64-linux-gnu -lSDL2

[0cjs]

I did a bit of debugging in build/libraries.py, and SDL2_ttf.getCompileFlags() does appear to be working correctly; it returns:

`sdl2-config --cflags` `pkg-config freetype2 --cflags`

On my system sdl2-config --cflags does produce the necessary output (including -I/usr/include/SDL2), which is why SDL2 itself is detected correctly. But for some reason that command's output is not included in SDL2_TTF_CFLAGS:= in derived/x86_64-linux-opt/config/probed_defs.mk. The issue seems to be in build/probe.py's resolution of getCompileFlags()'s result, according to a few debugging prints:

XXX checklibrary: makename=SDL2 library=<class 'libraries.SDL2'>
XXX checkLibrary: getCompileFlags=`sdl2-config --cflags`
XXX checkLibrary: cflags=-I/usr/include/SDL2 -D_REENTRANT
XXX checklibrary: makename=SDL2_TTF library=<class 'libraries.SDL2_ttf'>
XXX checkLibrary: getCompileFlags=`sdl2-config --cflags` `pkg-config freetype2 --cflags`
XXX checkLibrary: cflags=

Sadly, I can't seem to to figure out where your unit tests are for resolve() and its related functions, but I am guessing the problem is somewhere in there.

[mthuurne]

Manuel is running Debian testing, which is an in-development version that will eventually be the basis for the next release. So it's significantly newer than Debian 9.

Does pkg-config freetype2 --cflags work on your system?

There are no unit tests for the build system. If Meson can handle our cross builds, I'll migrate to that rather than continue to maintain our own system. But that's a long term solution; I'd also like to fix this issue in the current system.

[0cjs]

Ah, there's the problem:

$ pkg-config freetype2 --cflags
Package freetype2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `freetype2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'freetype2' found
1 $ apt-file search freetype2.pc
libfreetype6-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/freetype2.pc
$ apt list --installed libfreetype6-dev
Listing... Done
$ 

I am thinking that the routine that runs pkg-config should be failing with an error when the process exits with a code other than 0 (in this case, 1, just before my prompt above). That may point to a higher-level problem, that the build system doesn't check for the presence of the freetype dev package/libraries/whatever, or perhaps just indicating the failure above is enough.

[mthuurne]

The error should have been logged in the probe.log. For example, if I deliberately break it by searching for freetype3 instead, this is logged:

Error executing "pkg-config freetype3 --cflags"
Package freetype3 was not found in the pkg-config search path.
Perhaps you should add the directory containing `freetype3.pc'
to the PKG_CONFIG_PATH environment variable
Package 'freetype3', required by 'virtual:world', not found
Execution failed with exit code 1

[0cjs]

Ah, yes it is logged there:

Error executing "pkg-config freetype2 --cflags"                                     
Package freetype2 was not found in the pkg-config search path.                      
Perhaps you should add the directory containing `freetype2.pc'                      
to the PKG_CONFIG_PATH environment variable                                         
No package 'freetype2' found                                                        
Execution failed with exit code 1                                                   
compiler command: g++ -c derived/x86_64-linux-opt/config/SDL2_TTF.cc -o derived/x86_64-linux-opt/config/SDL2_TTF.o -m64
derived/x86_64-linux-opt/config/SDL2_TTF.cc:1:21: fatal error: SDL_ttf.h: No such file or directory
...

I was wondering about that, but because the probe continued on I had assumed that the failure was not fatal. Having now looked at the code, it seems to me that backtick expansions that fail during attempted execution at that point should be treated as fatal errors, because it means that something further up the chain got something wrong, or alternatively what's further up the chain is passing in commands that may fail and should be caught.

(That is to say, I'm still not clear on whether there should have been a test for freetype2's dev files being present or whether it's acceptable to make this attempted execution of pkg-config freetype2 be the test for that. I have no particular opinion either way, though I think that failing with an exception where it's run would be simpler, and presumably the people seeing such a failure would be developers that would quickly understand what the issue is when they see the command that failed.)

[mthuurne]

Ideally, we wouldn't need the FreeType compile flags at all, since FreeType is an implementation dependency of SDL2_ttf. But we do need the link flags when linking statically and the probe system does not separate implementation dependencies from interface dependencies, where we do need the compile flags (like SDL2_ttf needing SDL2's headers).

But as I wrote earlier, I'd rather adopt an existing build system (Meson being the prime candidate) than redesign our custom one.

Anyway, does openMSX build on your machine now? If so, we can close this ticket.

[0cjs]

Well, it will probably build if I install libfreetype6-dev. But this issue is really about the build system not really informing me that lack of that package is the problem. If you think that's not a big deal we can close the ticket, but I would prefer to see a clear, fatal error generated when that backtick command fails to execute, rather than the build system treating it as successfully saying "no parameters are needed for these variables," especially when the key parameter here (-I /usr/include/SDL2) was actually generated, but dropped by the build system.

[mthuurne]

Normally I'd agree with you, but since it's likely the build system is going to be replaced soon, I don't really want to spend time on it now.

[bferguson3]

I just hit this exact same error. Huge thanks to @0cjs for managing to research the cause.

Since this is over a year old now, maybe its worth taking the time to add libfreetype6-dev to hard dependencies?

[MBilderbeek]

@mthuurne Is there something simple we can do? E.g. detect this error and make a special warning for it?