I thought of looking closer at some core-updates failures and looked at this evaluation:
https://hydra.gnu.org/eval/109914?full=1&compare=109912 Randomly I stumbled over a failing teeworlds: https://hydra.gnu.org/job/gnu/core-updates/teeworlds-0.6.4.x86_64-linux The currently latest build is: https://hydra.gnu.org/build/2437799 The last lines of the build are this: src/engine/client/text.cpp: In member function ‘void CTextRender::RenderSetup(CFont*, int)’: src/engine/client/text.cpp:425:46: error: ‘FT_Set_Pixel_Sizes’ was not declared in this scope FT_Set_Pixel_Sizes(pFont->m_FtFace, 0, size); ^ src/engine/client/text.cpp: In member function ‘float CTextRender::Kerning(CFont*, int, int)’: src/engine/client/text.cpp:431:76: error: ‘FT_Get_Kerning’ was not declared in this scope FT_Get_Kerning(pFont->m_FtFace, Left, Right, FT_KERNING_DEFAULT, &Kerning); ^ src/engine/client/text.cpp: In member function ‘virtual void CTextRender::Init()’: src/engine/client/text.cpp:459:32: error: ‘FT_Init_FreeType’ was not declared in this scope FT_Init_FreeType(&m_FTLibrary); ^ src/engine/client/text.cpp: In member function ‘virtual CFont* CTextRender::LoadFont(const char*)’: src/engine/client/text.cpp:470:70: error: ‘FT_New_Face’ was not declared in this scope if(FT_New_Face(m_FTLibrary, pFont->m_aFilename, 0, &pFont->m_FtFace)) ^ bam: ret=256 g++ -Wall -fno-exceptions -fno-exceptions -Wall `sdl-config --cflags` `freetype-config --cflags` -O2 -c -DCONF_RELEASE -I "src" -I "other/freetype/include" -o objs/engine/client/text.o src/engine/client/text.cpp bam: 'objs/engine/client/text.o' error 256 bam: error: a build step failed phase `build' failed after 19.3 seconds builder for `/gnu/store/lv3mx8580296yfs7cr30aha05c7n77g6-teeworlds-0.6.4.drv' failed with exit code 1 @ build-failed /gnu/store/lv3mx8580296yfs7cr30aha05c7n77g6-teeworlds-0.6.4.drv - 1 builder for `/gnu/store/lv3mx8580296yfs7cr30aha05c7n77g6-teeworlds-0.6.4.drv' failed with exit code 1 That looks like freetype. And yes, in 5bb20a25078f79429a015c928a5d0c0efabef25e freetype was updated from 2.8 to 2.8.1. Since then, the build is broken. With the latest core-updates, I can reproduce the error. When I then revert the freetype version to 2.8, I can locally build and run teeworlds properly. I then saw the two commits 48342a04ada2df164df08c2532a2c424564da36f 7c291296955ed926377810cb61e251a808f98717 that are fixing freetype-related problems in other packages by adding pkg-config as a native-input. When I try that with teeworlds and freetype 2.8.1 (i.e. latest core-updates), teeworlds build is working fine again. So far, so good. That's a one-liner patch I could supply. But I also noticed that there are directories other/freetype and other/sdl, which contain Windows DLLs and freetype/sdl headers. I tried to snip them away entirely and tried to substite* the imports in 'bam.lua': diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm index 51f158d93..327a12edb 100644 --- a/gnu/packages/games.scm +++ b/gnu/packages/games.scm @@ -4608,7 +4608,10 @@ small robot living in the nano world, repair its maker.") '(begin (for-each delete-file-recursively '("src/engine/external/wavpack/" - "src/engine/external/zlib/")) + "src/engine/external/zlib/" + "other/freetype" + "other/sdl" +)) #t)) (patches (search-patches "teeworlds-use-latest-wavpack.patch")))) @@ -4638,7 +4641,10 @@ small robot living in the nano world, repair its maker.") "if true then") (("wavpack = .*") "wavpack = {} -settings.link.libs:Add(\"wavpack\")\n")) +settings.link.libs:Add(\"wavpack\")\n") + (("^Import.*other/sdl/sdl.lua.*") "\n") + (("^Import.*other/freetype/freetype.lua.*") "\n") +) (substitute* "src/engine/client/sound.cpp" (("#include <engine/external/wavpack/wavpack.h>") "#include <wavpack/wavpack.h>")) But that failed. I finally managed to substitute* all SDL/freetype related entried from bam.lua, but then the compile fails because SLD.h is no longer found. Here, my knowledge of/interest in bam is at its end. So: 1) Anybody volunteering for totally snipping away the SDL/freetype externals? 1a) If not, we should at least snip away the DLLs and apply the pkg-config patch. 2) Unrelated: Are there more candidates in core-updates that fail and have a freetype dependency? How can we figure that out? Björn