ok to commit ? emake DESTDIR="${D}" install || die dodoc AUTHORS ChangeLog NEWS README || die + # This might look like we're hardcoding libdir to /usr/lib, + # but that isn't the case. The only time $libdir gets used + # is with `gpg-error-config --libs`, and that's to output + # -L$libdir. Which we don't want. But the script itself + # filters out -L/usr/lib, so let's force the string to that + # so that -L$libdir is always removed. + dosed "/^libdir/s:=.*:=/usr/lib:" /usr/bin/gpg-error-config || die + if ! use common-lisp; then rm -fr "${ED}usr/share/common-lisp" || die fi
This is a _very_ nasty hack.. why not simply patching the script to not append any libdir at all, and submit that upstream?
the whole config script is a pile of crap. patching it makes no difference. the correct thing would be to convert it to a .pc file, but again, upstream takes forever on this kind of crap.
Fixed.
And so much for upstream taking forever: my patch is applied in libgpg-error repository already. Have a nice day.
congratulations on being lucky. would you like a cookie or something ? the last patch i posted took 7 months to change one word. however, your patch doesn't fix all the cases like mine did. you're thinking way too narrowly: not everyone is using /usr/lib or /usr/lib64.
Update the patch (and send the change upstream) if you wish to blacklist another library, or come up with a quick way to check the link path, for what I'm concerned on the current situation, this is fixed.
the ebuild in the tree is broken. it doesn't matter if you don't care about the ABIs where it is broken. my patch however fixes it for all ABIs. if you want to go a different route, then feel free to fix your patch to work correctly.
And yours is a hack that I'm not going to keep around forever. While I can _guess_ where it might be a problem for you, being a gentoo developer does not exempt you from providing proper fixes if you want to have them integrated. You can either come up with a proper fix following the lines of the one I already applied for lib64, or you can stop bothering us. I'm not going to allow hacks that require six lines of explanation and that can't be upstreamed when a good change would be adding one line to a patch. I give you a choice: you can suggest a way to fetch the library search path from the link editor so that it can skip over those libraries, and I'll flesh out the patch for upstream. Or you can propose on gnupg-devel to replace gpg-error-config with pkg-config (and possibly a wrapper around it), and again I'll help you out with the details to flesh if you don't want to follow through with them. But I'm not going to allow your hacks just because you can't be bothered spending time on the correct fix.
the gpg config script has no real business executing the compiler driver to discover what paths might be available. since it has already opted into scanning lib paths, then fixing that filter is the logical next step. as to the exact fix, it's is fairly obvious if you simply look at how ABIs are handled (which is fully documented in the obvious multilib.eclass): they start with "lib" and have an arbitrary suffix. migrating to a .pc file is a long term solution which doesn't make existing packages work. you insist on updating the existing config script, so update it properly. the comments are to help people understand. if you want less documentation, that's trivial to resolve.
Diego's fix broke configuring on non-Linux platforms, or when using a shell like dash. Solaris/MacOSX (with bash): config.status: creating src/versioninfo.rc config.status: creating config.h config.status: executing depfiles commands ./config.status[1400]: shift: (null): bad number Libgpg-error v1.10 has been configured as follows: Platform: x86_64-pc-solaris2.11 >>> Source configured. build fails due to libtool not being created. all platforms with dash as CONFIG_SHELL (this is on Gentoo Linux amd64): % env CONFIG_SHELL=/bin/dash ebuild libgpg-error-1.10-r1.ebuild digest clean configure ... config.status: creating src/versioninfo.rc config.status: creating config.h config.status: executing depfiles commands ./config.status: 1404: shift: can't shift that many !!! Please attach the following file when seeking support: !!! /var/tmp/portage/dev-libs/libgpg-error-1.10-r1/work/libgpg-error-1.10/config.log * ERROR: dev-libs/libgpg-error-1.10-r1 failed (configure phase): The problem is absent in libgpg-error-1.10. Please add eautoreconf or another sufficient fix (for Prefix).
(In reply to comment #10) are you sure about that ? Diego's change should have nothing to do with how configure (and the generated config.status) behave.
You're right. The problem is not introduced by the patch, but rather by the difference in EAPI: 0.10 is 3, wheras 0.10-r1 is 4. The latter uses --disable-dependency-tracking, which causes the problem. Therefore the eautoreconf solves the problem, it updates the autotools to something recent/non-broken. Sorry about that, didn't do enough testing yesterday.
Nothing to do here for Prefix
(In reply to Fabian Groffen from comment #13) > Nothing to do here for Prefix This should be solved upstream anyways, so closing this bug while at it
