(address . bug-guix@gnu.org)
20180218214636.006a7f6d@alma-ubu
I thought of looking closer at some core-updates failures and looked at
this evaluation:
Randomly I stumbled over a failing teeworlds:
The currently latest build is:
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':
Toggle diff (45 lines)
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