* QA Notice: The following files contain insecure RUNPATHs * Please file a bug about this at http://bugs.gentoo.org/ * with the maintaining herd of the package. * /var/tmp/portage/net-print/gutenprint-5.2.7/image/usr/libexec/cups/filter/rastertogutenprint.5.2 * /var/tmp/portage/net-print/gutenprint-5.2.7/image/usr/libexec/cups/driver/gutenprint.5.2 * /var/tmp/portage/net-print/gutenprint-5.2.7/image/usr/sbin/cups-genppd.5.2 * The ebuild is CVS version 1.2, so the problem might come from the fix for bug #382027.
Well, for a start, the whole '--disable-static-genppd' problem seems to be a KDE type of autotools bug, where improper use of a tool tends to give you invalid results. I don't know whether either maintainer or upstream would be interested in a real fix, but I might give a shot at a real fix.
Created attachment 286445 [details, diff] fix improper use of autotools OK, local libtool scripts look promising, so could you see if this patch helps with bug 382027 after reverting current "fix". I'm unsure if the fix is complete, but for the moment it should be enough.
To clarify, the only part to revert would be '--enable-static-genppd', the other part is actually required for the fix to take effect.
(In reply to comment #2) > Created attachment 286445 [details, diff] > fix improper use of autotools > > OK, local libtool scripts look promising, so could you see if this patch helps > with bug 382027 after reverting current "fix". > > I'm unsure if the fix is complete, but for the moment it should be enough. Did you even try this? Just wondering since it doesn't work for me. Anyway, this is probably caused by a libtool bug similar to that discussed at http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7440/focus=7445 Also, the issue is documented quite a bit in the NEWS file from the package's tarball. These problems manifested when I added the static-libs use flag to the package and this rpath problem could be "fixed" by forcing people to build with the static-libs use flag enabled when the genppds flag is enabled, at least until libtool is fixed.
(In reply to comment #4) > These problems manifested when I added the static-libs use flag to the package > and this rpath problem could be "fixed" by forcing people to build with the > static-libs use flag enabled when the genppds flag is enabled, at least until > libtool is fixed. And when I say genppds use flag, I mean the ppds flag of course. :)
Well, I haven't tested it in portage, just did a quick manual build, where i.e. libtool scripts generated in src/cups *prepended* $(top_builddir)/src/main/.libs to LD_LIBRARY_PATH. Regardless, I'm nearly certain it *is* a KDE type of autotools bug - the patch I've attached is correct regardless of whether or not if *seems* to fix anything, as gutenprint upstream should reference neither libgutenprint nor libgutenprintui2 via '-l<libname>' in their Makefile.am files if they build it. But as I said, it might not be complete yet. I'll give a portage build a shot eventually, but as I don't actually use gutenprint, the only thing I'll be able to say will be if it builds. As for it being documented in NEWS file, once upon a time, KDE upstream "documented" autotools "bugs" on many of its help pages - nearly all of them came from the broken way kdevelop generated its autotools "templates". As for the thread you've referenced, I'd say it's inconclusive, as the last post is a repeated question for a debug log.
(In reply to comment #6) > Well, I haven't tested it in portage, just did a quick manual build, where i.e. > libtool scripts generated in src/cups *prepended* > $(top_builddir)/src/main/.libs to LD_LIBRARY_PATH. > ... snip ... I wasn't questioning the validity of your patch. It just didn't work so I wanted state that. > As for it being documented in NEWS file, once upon a time, KDE upstream > "documented" autotools "bugs" on many of its help pages - nearly all of them > came from the broken way kdevelop generated its autotools "templates". I didn't mean that their documentation validates the broken behavior, I was just stating that it probably should at least be glanced at by people trying to fix this bug. > As for the thread you've referenced, I'd say it's inconclusive, as the last > post is a repeated question for a debug log. It wasn't supposed to be conclusive, it was supposed to show that this bug probably relates to an upstream libtool issue.
It should also be noted that the build failure related to ppd generation as seen in bug #382027 will only occur if you are upgrading gutenprint and building it with static-libs disabled. (Again the specifics are documented in the tarball.) Therefore, if you are manually building gutenprint or installing it for the first time you won't run into the issue.
Created attachment 286543 [details, diff] fix stdio.h includes Well, if all that's needed to trigger it is an upgrade 5.2.6 -> 5.2.7, I, on the other hand, can't reproduce it at all - even without my patch. If I do use it, after reverting the ebuild to its first revision, then adding autotools to inherit and making: src_prepare() { mkdir m4local epatch "${FILESDIR}/${PN}-5.2.4-CFLAGS.patch" epatch "${FILESDIR}/fix-linking.patch" epatch "${FILESDIR}/fix-gcc-4.5.patch" eautoreconf } it upgrades cleanly - I'm on x86, but that shouldn't matter. That fix-gcc-4.5.patch is actually more like for glibc 2.13 - see for yourself. Could you attach the config.log from such failed build (and the generated scr/cups/cups-genppd.5.2 libtool script) ? I'm beginning to suspect, that the real problem here (at least the part not solved by my patch) is the other, likely valid concern in that NEWS file - broken cups-config output (or more exactly, a broken krb5-config script - AFAIK, both mit and heimdal are broken in that regard (I simply have hacked that script - the heimal one - to pieces in my local overlay)).
(In reply to comment #9) > Created attachment 286543 [details, diff] > fix stdio.h includes > > Well, if all that's needed to trigger it is an upgrade 5.2.6 -> 5.2.7, I, on > the other hand, can't reproduce it at all - even without my patch. Just to confirm, you've installed 5.2.6 and then you're upgrading to 5.2.7 with USE="-static-libs ppds" set? That triggers it here.
(In reply to comment #10) > > Just to confirm, you've installed 5.2.6 and then you're upgrading to 5.2.7 with > USE="-static-libs ppds" set? That triggers it here. Make that USE="-static-libs ppds cups" of course.
(In reply to comment #11) > (In reply to comment #10) > > > > Just to confirm, you've installed 5.2.6 and then you're upgrading to 5.2.7 with > > USE="-static-libs ppds" set? That triggers it here. > > Make that USE="-static-libs ppds cups" of course. That's just the thing - I did just that, several times (even set foomaticdb in hope of triggering) and couldn't reproduce. That's why I'm requesting config.log and the libtool wrapper script.
Created attachment 286577 [details] Failing config.log
Created attachment 286579 [details] libtool script
Created attachment 286581 [details] shell trace of libtool run I haven't downgraded gutenprint (yet), but it failed for me on last update, and I still get /usr/lib64 prefixed into the libtool-generated script (which is identical to the one from comment #14). Trying to investigate where that prefix came from, I've run libtool the application (sys-devel/libtool-2.4-r1) just like the makefile does, but captured its process: $ PS4='${LINENO} + ' /bin/sh -x ../../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -DALL_LINGUAS='"cs da de el en_GB es fi fr hu it ja nb nl pl pt ru sk sl sv zh_TW"' -Disfinite=finite -march=amdfam10 -O2 -ggdb -pipe -Wl,--as-needed -o cups-genppd.5.2 cups_genppd_5_2-genppd.o cups_genppd_5_2-i18n.o -lcupsimage -lcups -L/usr/lib64 -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -L/usr/lib -lcrypto -lasn1 -lwind -lroken -lcrypt -pthread -ldl -lresolv -pthread -lgnutls -L/usr/lib64 -lgcrypt -lgpg-error -lz -lpthread -lm -lcrypt -lz ../../src/main/libgutenprint.la 2>&1 | tee libtool.trace So that's the file I'm attaching here. Given enough time, it should enable you to see where certain values come from. Relevant lines I've found: 7078 + temp_rpath+=/usr/lib64: # that's the variable included in the wrapper That variable appears at the place where -lgssapi is handled, after -L/usr/lib64 was handled. This order seems to come from cups-config: $ cups-config --libs -lcups -L/usr/lib64 -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -L/usr/lib -lcrypto -lasn1 -lwind -lroken -lcrypt -pthread -ldl -lresolv -pthread -lgnutls -L/usr/lib64 -lgcrypt -lgpg-error -lz -lpthread -lm -lcrypt But even removing those -L switches from the CUPS_LIBS makefile variable doesn't make the path disappear from LD_LIBRARY_PATH in the wrapper script.
Created attachment 286591 [details, diff] Fix 382027 by changing library order OK, it appears that this is all about order. Libtool gets passed a list of libs to use, among them libgssapi from $(CUPS_LIBS) installed in /usr/lib64 as well as libgutenprint from $(GUTENPRINT_LIBS) to be taken from the current build. But LD_LIBRARY_PATH selects directories, not files. And we want the directory of the currently built libgutenprint to precede that of the system installed libgssapi or similar. So the solution is easy: make sure $(GUTENPRINT_LIBS) precedes all other libs, $(CUPS_LIBS) in particular. As to why some people can reproduce bug #382027, and others cannot, I can only speculate. At least on my system, it appears that libtool changes the -lgssapi argument into /usr/lib64/libgssapi.so passed to the linker. This also seems to be the point where the /usr/lib64 directory is added to temp_rpath. The reason for this change appears to be the fact that there is a libtool file libgssapi.la installed on my system. So perhaps a different set of libtool files will make a change. If you really want to know, please paste the libtool invocation and output from a build which failed to reproduce the bug. So, if we use this to fix bug #382027, and drop the --enable-static-genppd configure flag, we should be safe wrt this RUNPATH issue as well, right?
(In reply to comment #15) > Created attachment 286581 [details] > shell trace of libtool run > > I haven't downgraded gutenprint (yet), but it failed for me on last update, and > I still get /usr/lib64 prefixed into the libtool-generated script (which is > identical to the one from comment #14). Trying to investigate where that prefix > came from, I've run libtool the application (sys-devel/libtool-2.4-r1) just > like the makefile does, but captured its process: ... I did the same thing and kept removing the related .la files until it compiled properly. :) For me, this was the following three libtool archives: /usr/lib64/lib{gcrypt,gnutls,gpg-error}.la, but it will depend on what use flags you have cups compiled with.
(In reply to comment #16) > So, if we use this to fix bug #382027, and drop the --enable-static-genppd > configure flag, we should be safe wrt this RUNPATH issue as well, right? Yep, I'll make a simple patch to fix the issue for genppd.
(In reply to comment #18) > Yep, I'll make a simple patch to fix the issue for genppd. Isn't my patch from comment #16 enough? Did the job for me. Or do you want to avoid having to eautoreconf the package? (In reply to comment #16) > Created attachment 286591 [details, diff] > Fix 382027 by changing library order Proposed this patch upstream: https://sourceforge.net/tracker/?func=detail&aid=3410214&group_id=1537&atid=301537
(In reply to comment #19) > (In reply to comment #18) > > Yep, I'll make a simple patch to fix the issue for genppd. > > Isn't my patch from comment #16 enough? Did the job for me. > Or do you want to avoid having to eautoreconf the package? > > (In reply to comment #16) > > Created attachment 286591 [details, diff] > > Fix 382027 by changing library order > > Proposed this patch upstream: > https://sourceforge.net/tracker/?func=detail&aid=3410214&group_id=1537&atid=301537 Sorry, already committed a similar patch to CVS along with Rafał's linking changes. :)
Regardless, my patch from comment 9 should still be useful - I honestly thought, that one of 2.13 revisions already is in stable. Most likely I couldn't reproduce the original problem cause I have significantly less la files installed than the current tree has.
