x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -Wall -Wdeclaration-after-statement -ffunction-sections -fdata-sections -fpic -Iinclude -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNO_ICC -DSHARE_JPEG -DFZ_ENABLE_JS=0 -I/usr/include/openjpeg-2.3 -o build/debug/platform/gl/gl-font.o -c platform/gl/gl-font.c In file included from platform/gl/gl-font.c:15:0: platform/gl/gl-app.h:11:10: fatal error: GL/freeglut.h: No such file or directory #include <GL/freeglut.h> ^~~~~~~~~~~~~~~ compilation terminated. ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-hardened_20180127-154825 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.2.0 * Available Python interpreters, in order of preference: [1] python3.5 [2] python2.7 (fallback) emerge -qpv app-text/mupdf [ebuild N ] app-text/mupdf-1.11-r2 USE="curl openssl -X -javascript -libressl -opengl -static -static-libs -vanilla"
Created attachment 516980 [details] emerge-info.txt
Created attachment 516982 [details] app-text:mupdf-1.12.0:20180128-111804.log
Created attachment 516984 [details] emerge-history.txt
Created attachment 516986 [details] environment
Created attachment 516988 [details] etc.portage.tbz2
Created attachment 516990 [details] temp.tbz2
Very likely due to this commit: http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=896830e23e8f94b17bdf386c191a885c972ea8a8 src_prepare() does a sed on Makerules and sets HAVE_GLFW. Replacing that with HAVE_GLUT doesn't quite work, but it *does* subsequently build via 'make HAVE_GLUT=no', so apparently Makefile needs to be patched too. That's all I got for now..
Oneshotting freeglut allowed me to emerge mupdf without issue. Pulling in media-libs/freeglut as a dep might be a simple solution but it seems to be a more complex issue than this. maybe it's resolvable by making freeglut a useflag?
(In reply to Lander Ghekiere from comment #8) > Oneshotting freeglut allowed me to emerge mupdf without issue. > > Pulling in media-libs/freeglut as a dep might be a simple solution but it > seems to be a more complex issue than this. maybe it's resolvable by making > freeglut a useflag? Changing the "opengl" dependency to freeglut would be correct for the case where "opengl" is requested (e.g. when building the GUI version of mupdf) but the issue here is not to force it to build but rather to build it *without* opengl at all (on headless systems), which changed in the build. The current ebuild also needs to be fixed for the additional new bundled lcms dependency, but that's a different story. Right now it seems to build more or less by accident.
Interesting how some packages are pushed even though they clearly don't compile, One would think that the person who pushed this actually tried to compile it first, but nah ... it's more fun to agitate users and then discuss on bugzilla how to solve build problems.
Created attachment 517116 [details, diff] replace glfw with freeglut
Attaching a small patch which at least solves the issue for me locally. I have not checked if 1.11-system-glfw.patch needs to be updated for freeglut (I don't use opengl myself) so I blanked it out for now. It's probably best served as a reference - this is not tested with opengl. Makerules has been updated upstream to override any HAVE_GLUT set from sed in the ebuild (which has itself been sed'd with this patch to do conditional assignment).
(In reply to Kajzer from comment #10) > Interesting how some packages are pushed even though they clearly don't > compile, One would think that the person who pushed this actually tried to > compile it first, but nah ... it's more fun to agitate users and then > discuss on bugzilla how to solve build problems. Well, I'm not sure how the process usually goes but if somebody had freeglut installed for any other reason before this happened it could've easily slipped by. Catching every possible scenario (USE flags, installed packaged, w/e) can be very time consuming and is not such an easy task.
This worked for me, obviously I don't need opengl/freeglut : --- mupdf-1.12.0-source/Makerules +++ mupdf-1.12.0-source/Makerules @@ -114,7 +114,7 @@ SYS_PTHREAD_CFLAGS := SYS_PTHREAD_LIBS := -lpthread -HAVE_GLUT := yes +HAVE_GLUT := no SYS_GLUT_CFLAGS := SYS_GLUT_LIBS := -lglut -lGL
Seems to me that there also needs to be an explicit RDEPEND for freeglut if the opengl USE flag is set. freeglut is pulled in by seveal other graphical pkgs during an install, so it could have just slippen by in testing.
(In reply to Kajzer from comment #14) > This worked for me, obviously I don't need opengl/freeglut : > > --- mupdf-1.12.0-source/Makerules > +++ mupdf-1.12.0-source/Makerules > @@ -114,7 +114,7 @@ > SYS_PTHREAD_CFLAGS := > SYS_PTHREAD_LIBS := -lpthread > > -HAVE_GLUT := yes > +HAVE_GLUT := no > SYS_GLUT_CFLAGS := > SYS_GLUT_LIBS := -lglut -lGL As it turns out this is patching of Makerules is no longer necessary; it will build fine when the various HAVE_XY flags are passed to the toplevel Makefile, which seems to be the official way now. I hope to create an updated ebuild & Github PR in the next few days.
Created attachment 518730 [details] Updated ebuild for headless systems & less random build success No PR but for now "just" an updated ebuild for review & further improvement. This entire thing is quite the dumpster fire - partly because the upstream build system changed significantly in 1.12, partly because the ebuild has to fix things that upstream hates (e.g. shared libs) in pretty intrusive ways. The attached ebuild for -r1 fixes several things: - changed dependency from glfw to freeglut - removed patch for system glfw - unbundled freeglut - moved various WANT_X and HAVE_X flags from being patched into Makerules by src_prepare to flags that are passed to Makefile in src_compile (or otherwise it just won't work since Makefile passes flags with default values in and so overrides the patched values). Instead of patching Makerules an alternative might be to change the defaults in the toplevel Makefile instead. The result now builds/installs/works fine both on my headless system (-X -opengl) as on my desktop workstation (+X +opengl), so that is an improvement. Things I'm not happy about: - the bundled lcms2 lib is actually a fork, so it must stay bundled. - the fact that we're still patching around in Makerules *at all* seems bizarre, but I've tried to eliminate that and stuff just broke with sandbox violations due to install locations not being configured properly. It should be possible to pass those in via Makefile as well, but somehow I couldn't make it work. - duplication of the WANT/HAVE flags in both src_compile and src_install. I tried to make that global but apparently use flag reading is not possible in global contexts (portage complains). - building with +javascript against mujs still works, but static linking via +static and/or +static-libs is probably broken, but I have no way to test that. Ironic considering that upstream has this misguided static linking fetish. Considering that (AFAIK) there don't seem to be any packages linking against libmupdf other than the mupdf tools themselves, an easier way forward might be to nuke all this shared lib hackery, and build the tools as vanilla as possible, with only minimal build intrusion for using/fixing 3rd party dependencies.
*** Bug 646828 has been marked as a duplicate of this bug. ***
Created attachment 520546 [details] build.log confirming
Has there been any more progress on resolving this? I am still running into this issue.
Indeed, 2 months later and multiple user supplied patches and we still haven't pushed this to the tree...
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68602054995f198e5b0a4b591afa7fd1c2aa7799 commit 68602054995f198e5b0a4b591afa7fd1c2aa7799 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2018-04-11 20:21:33 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-04-11 20:23:25 +0000 app-text/mupdf: Use freeglut instead of glfw Closes: https://bugs.gentoo.org/645948 Package-Manager: Portage-2.3.28, Repoman-2.3.9 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> app-text/mupdf/mupdf-1.12.0-r1.ebuild | 166 ++++++++++++++++++++++++++++++++++ 1 file changed, 166 insertions(+)
Thank you Holger!
*** Bug 651042 has been marked as a duplicate of this bug. ***
