Build fails on Arch Linux with Pango 1:1.44.6-1
nstickney opened this issue · comments
I feel like this happens to you every few years (#3, #18). Anyway, we are once again failing to build and I haven't been able to turn up any easy solutions to implement at the package level. Error shown below.
[bash 5.0.9] $ aurman -S dwarffortress-ironhand
~~ initializing aurman...
~~ calculating solutions...
:: The following 1 package(s) are getting reinstalled:
aur/dwarffortress-ironhand 0.44.12-1 -> 0.44.12-1
?? Do you want to continue? Y/n:
~~ looking for new pkgbuilds and fetching them...
==> Making package: dwarffortress-ironhand 0.44.12-1 (Mon 23 Sep 2019 09:09:13 PM EDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found dwarffortress-unfuck-0.44.12.tar.gz
-> Found dwarffortress
-> Found dwarffortress.desktop
-> Found Ironhand_44_12A.zip
-> Found dwarffortress.png
-> Found df_44_12_linux.tar.bz2
==> Validating source files with sha256sums...
dwarffortress-unfuck-0.44.12.tar.gz ... Passed
dwarffortress ... Passed
dwarffortress.desktop ... Passed
Ironhand_44_12A.zip ... Passed
dwarffortress.png ... Passed
==> Validating source_x86_64 files with sha256sums...
df_44_12_linux.tar.bz2 ... Passed
==> Extracting sources...
-> Extracting dwarffortress-unfuck-0.44.12.tar.gz with bsdtar
-> Extracting Ironhand_44_12A.zip with bsdtar
-> Extracting df_44_12_linux.tar.bz2 with bsdtar
==> Removing existing $pkgdir/ directory...
==> Starting build()...
CMake Warning (dev) at /usr/share/cmake-3.15/Modules/FindOpenGL.cmake:275 (message):
Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when
available. Run "cmake --help-policy CMP0072" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
FindOpenGL found both a legacy GL library:
OPENGL_gl_LIBRARY: /usr/lib/libGL.so
and GLVND libraries for OpenGL and GLX:
OPENGL_opengl_LIBRARY: /usr/lib/libOpenGL.so
OPENGL_glx_LIBRARY: /usr/lib/libGLX.so
OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for
compatibility with CMake 3.10 and below the legacy GL library will be used.
Call Stack (most recent call first):
CMakeLists.txt:8 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/aurman/dwarffortress-ironhand/src/dwarf_fortress_unfuck-0.44.12
Scanning dependencies of target graphics
[ 4%] Building CXX object CMakeFiles/graphics.dir/g_src/enabler.cpp.o
In file included from /usr/include/pango-1.0/pango/pango-attributes.h:25,
from /usr/include/pango-1.0/pango/pango.h:25,
from /usr/include/gtk-2.0/gdk/gdktypes.h:37,
from /usr/include/gtk-2.0/gdk/gdkscreen.h:32,
from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
from /usr/include/gtk-2.0/gdk/gdk.h:32,
from /usr/include/gtk-2.0/gtk/gtk.h:32,
from /tmp/aurman/dwarffortress-ironhand/src/dwarf_fortress_unfuck-0.44.12/g_src/enabler.cpp:4:
/usr/include/pango-1.0/pango/pango-font.h:29:10: fatal error: hb.h: No such file or directory
29 | #include <hb.h>
| ^~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/graphics.dir/build.make:89: CMakeFiles/graphics.dir/g_src/enabler.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/graphics.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
2019-09-23 21:09:16,250 - wrappers - makepkg - ERROR - makepkg query ['makepkg', '-cf', '--noconfirm'] failed in directory /tmp/aurman/dwarffortress-ironhand
My Ducking turned up a few things, mostly above my knowledge level:
that's a bug in pango that was apparently fixed here: https://gitlab.gnome.org/GNOME/pango/issues/387
you should wait for the next pango release or demand that arch maintainers backport the fix.
Figures. Thanks, and cheers for your work!!!
Good find. You should post a bug on our Arch bug tracker about it. It'll likely get backported. If nobody picks up the bug in a few days, ping me directly and I'll do it.
@rofl0r @svenstaro I took a deeper look, and the referenced bug in Pango is already fixed in the version currently shipping with Arch --- in fact, it's the referenced bugfix that causes this issue for me.
A specific comment on that bug (from the developer who posted the fix) says,
When you build against harfbuzz, you use the harfbuzz.pc file, which adds /usr/include/harfbuzz to the include paths. So using hb.h is correct. And that is what we are using internally in pango sources. There's a slight question about public headers, since those get used by third parties when building against pango, not against harfbuzz. But I've added harfbuzz to the Requires in pangos pkgconfig file now.
I can't pretend I know about the proper way to include harfbuzz, but that does seem to be the issue.
check whether pkg-config --cflags pango displays harfbuzz include paths. if it doesn't it seems the problem is not fixed on your install. if it does, it should work.
Fixed in 82ba385
"fixed" ? this merely changes for whom it breaks. those that use pre-harfbuzz pango (me included) will now run into an error.
I assumed this was an older change. What do you propose? I suppose if it truly is an older change, specifying a minimum pango version would be a good way to make sure that users run a recent enough pango?
is harfbuzz a direct dependency of dfu ? if not it's not its business to deal with it.
this is clearly an oversight of the pango developers (now fixed) that they made their public headers depend on it without adding the implicit inclusion of pkg-config dependencies.
the solution is simply to only check for pango, just as in the past (i.e. do nothing on your side - "Not my problem").
specifying a minimum pango version
why ? even 5 year old pangos should work fine, if the install isn't buggy.
So I checked: pango 1.31.1 (which was released 7 years ago) started depending on harfbuzz so it should not be an effective problem for people on any currently supported distros to depend directly on harfbuzz. We shouldn't depend on non-direct dependencies but sometimes that's what it takes to make things build.
Anyway, I looked into the upstream issue and the fix and the problem is that they only fixed the pkg-config file and not the CMake file in the CMake source tree so this is why this problem remains. I switched to pkg_config for this. I also modernized to GTK3 in the meantime so that we don't block distros trying to drop GTK2 in the future.
See if ba56d56 works for you.
Anyway, I looked into the upstream issue and the fix and the problem is that they only fixed the pkg-config file and not the CMake file in the CMake source tree
i see. yet another reason not to use cmake :-)
I switched to pkg_config for this
great, this seems to be the right fix
I also modernized to GTK3
bummer, i don't have GTK3 installed so i can't test. i've been relying on the GTK2 support.
If for some reason you're unable to use GTK3, I'd accept a patch which used pkg_config to figure out whether you have GTK3 and then falls back to GTK2 if the former is untrue.
Or in fact, if you really want to go all out on this, I'd even accept a patch to for a meson-based build system.
I'd accept a patch which used pkg_config to figure out whether you have GTK3 and then falls back to GTK2
that sounds reasonable, i might give it a try
I'd even accept a patch to for a meson-based build system
that goes too far, meson is even worse than cmake in that it requires bleeding edge python3 features (which is intended, as the meson guys admit themselves that they want to force distros to have latest and greatest py3 installed, so they can use it unconditionally for all their tooling).
as an almost one-man-show distro maintainer, my stance on introducing new dependencies is conservative (so far i've successfully avoided to get any meson-only projects into the package list).
btw if you're interested, i wrote a blog post about C++ build systems here https://sabotage-linux.github.io/blog/5/