I've just updated icewm today after installing the package yesterday for the first time. (Nothing strange, I've just decided to clean up consolekit policykit USE flags out of my system today; so I had to rebuild a few packages.) Compilation fails because of... the title says it all. Here is a sample of build error: --- icewmhint.o: In function `main': icewmhint.cc:(.text.startup+0xf2): undefined reference to `XOpenDisplay' icewmhint.cc:(.text.startup+0x130): undefined reference to `XInternAtom' icewmhint.cc:(.text.startup+0x167): undefined reference to `XChangeProperty' icewmhint.cc:(.text.startup+0x173): undefined reference to `XCloseDisplay' collect2: error: ld returned 1 exit status Makefile:1339: recipe for target 'icewmhint' failed make[2]: *** [icewmhint] Error 1 --- I've just fixed the build error by adding manually the missing libraries in `src/Makefile' to get going. The maintainer (polynomial) did a great job fixing frbidi related dependencies in the `configure.ac' file. However, compilation failed. The offending line(s) (in `configure.ac') is: --- PKG_CHECK_MODULES([CORE],[fontconfig x11 xext]) AC_SUBST([CORECFLAGS]) AC_SUBST([CORE_LIBS]) --- which end up by not putting anything in those two variables generating the issue. No luck trying to add a user patch because the package lack any `epatch_user' in `src_prepare()'. I tried to edit `configure.ac' directly before preparing the source to test the following patch... but `icewm-1.3.9-fribidi.patch' fails afterwards (which shouldn't happen!). Enough. Alas, I'm attaching a untested patch because I cannot test it without copying the ebuild and... Anyway, the fix is just splitting the offending expression in three parts and then update `CORE_{CFLAGS,LIBS}' accordingly. I am not that proefficient with autotools, so I don't know if the attached patch will work. I will leave the rest for another contributor. (I may test/finish the patch later... I've just had enough.) Reproducible: Always
Created attachment 388540 [details, diff] icewm-1.3.9-corelibs.patch
I encountered this issue on another package with a similar PKG_CHECK_MODULES, so I decided to debug a little more. Well, where to start? First, the attached patch is unecessary as it seems to be an autoconf issue. Actually pkg-config accepts several packages as arguments, so it's not an issue. I've just took a look on the generated configure script and specifically the related CORE bits, and, nothing is atually done to append C/LDFLAGS because of: --- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for CORE" >&5 $as_echo_n "checking for CORE... " >&6; } if test -n "$CORE_CFLAGS"; then (...) if test -n "$CORE_LIBS"; then (...) fi --- The faulty part should be as follow: --- if test -z "$CORE_CFLAGS"; then (...) if test -z "$CORE_LIBS"; then (...) fi --- And then the relevant bits of CORE_C/LDFLAGS would be rightly executed and get the magical right C/LDFLAGS! So this bug should be closed, I am openning a sys-devel/autoconf bug instead.
Openned bug #528290 instead.
I see, I wasn't aware of that bug... I encountered the other variant of his one,--I'm using ld.gold,-- where gold refuses openly to link to dynamic shared libraries (DSO) not specified on the command line. I got into this one quite a few times although I don't rememeber what I did to fix those issues--I did not open bugs for that, so I should have fixed them either by hand or by patching... (I should rethink a second time about using gold as my default linker. Ii don't extra beta testing for such an old issue.)
This bug should be fixed as it is not related to what I openned it for... or re-ttitled to the *underlinking issue*. I will wait for the autoconf maintainer response though.
I mean *closed* in the previous comment.
I am actually using ld.bfd... I switched back from gold for another reason. God, I don't remember anymore why I switched back. ld.gold throws away the same error anyway.
Created attachment 388584 [details, diff] files/icewm-1.3.9-fribidi.patch It looks like the fribidi patch is responsible. Classic issue of PKG_CHECK_MODULES being called conditionally when PKG_PROG_PKG_CONFIG has not been called yet? I would be able to tell if you had attached your build.log/config.log.
*** Bug 528290 has been marked as a duplicate of this bug. ***
Ah no, it's not just that. AC_ARG_ENABLE([fribidi] is run /before/ PKG_CHECK_MODULES([CORE], ...) so the latter "respects" the precious variables CORE_* that have been already set?
Yes, with USE=-bidi the build succeeds so it must be that.
Created attachment 388586 [details, diff] files/icewm-1.3.9-fribidi.patch It's better to move the fribidi checks after the PKG_CHECK_MODULES([CORE], ...) call.
Right, I did not pay attention to the order of frbidi related bits... it makes sense. I should be carefull with the place/order of PKG_PROG_PKG_CONFIG. That was a quick fix Jeroen, thanks! (I encountered similar issues before but I did not pay attention to PKG_CONFIG place.)
I updated upstream with a patch for fribidi that fixes several other issues as well. https://github.com/bbidulock/icewm/commit/800fc7caa9728cebafee86d841ac23b6ffaa896b I also notices that the -deprecated.patch does nothing.
Thanks, Brian. Somebody has to close this bug then.
+ 07 Nov 2014; Lars Wendler <polynomial-c@gentoo.org> icewm-1.3.9.ebuild, + files/icewm-1.3.9-fribidi.patch: + Fixed fribidi patch (bug #528254) and adjusted dependency on gettext (bug + #528318). +