| Summary: | media-sound/jack-audio-connection-kit: does not install its DSO's into LIBDIR | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Anthony Basile <blueness> |
| Component: | [OLD] Library | Assignee: | Professional Audio Applications Maintainers <proaudio> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | pms, radhermit |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=239190 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 239190 | ||
| Bug Blocks: | |||
wait, isnt econf supposed to do this already ? (In reply to comment #1) > wait, isnt econf supposed to do this already ? It doesn't set it to what is returned by $(get_libdir), rather it sets it to /usr/lib64. I could trace down why. (In reply to comment #2) > (In reply to comment #1) > > wait, isnt econf supposed to do this already ? > > It doesn't set it to what is returned by $(get_libdir), rather it sets it to > /usr/lib64. I could trace down why. IMHO this is something that should be fixed in econf itself: we wont be adding --libdir lines to everysingle autoconf ebuild. (In reply to comment #3) Sounds like bug 239190. (In reply to comment #4) > (In reply to comment #3) > Sounds like bug 239190. Yep, that's it. Now I've been going around bugging people to fix this because of all the alternative LIBDIR_${ABI} I work with. A fix within portage itself makes the most sense, but since this is some time in the future, what do we do in the mean time? (BTW, similar issue with imake, but that'll be another bug.) Yeah, portage econf behavior is governed by PMS for existing EAPIs. For now, you'll have to override the econf arguments to suit your needs. jack-audio-connection-kit is special (aka stupid):
## take care not to override the command-line setting
if test "${libdir}" = '${exec_prefix}/lib'; then
libdir='${exec_prefix}/'${libnn}
fi
so the change proposed in comment 0 would be fine as long as bug 239190 exists
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > wait, isnt econf supposed to do this already ? > > > > It doesn't set it to what is returned by $(get_libdir), rather it sets it to > > /usr/lib64. I could trace down why. > > IMHO this is something that should be fixed in econf itself: we wont be > adding --libdir lines to everysingle autoconf ebuild. Not every ebuild will need it. I've only uncovered a few where the build systems does something stupid, and this is one. Can we commit this fix until bug #239190 is resolved? (In reply to comment #8) I don't particularly like it but feel free to commit |
I hit this on profile = hardened/linux/uclibc/amd64, but it would affect all "exotic" multilib systems like mips with o32-n32-n64 abis. You hit it, eg, when trying to emerge pulseaudio with USE=jack. emerging jack-audio-connection-kit on any 64-bit system installs its DSO's into /usr/lib64, but it should install them into /usr/${LIBDIR} where LIBDIR is reported by $(get_libdir) inherited from multilib. The fix to the ebuild is pretty straight forward. I'll just inline the patch. Note multilib was inherited there twice --- harmless but lint. @@ -4,7 +4,7 @@ EAPI=2 -inherit flag-o-matic eutils multilib multilib +inherit flag-o-matic eutils multilib DESCRIPTION="A low-latency audio server" HOMEPAGE="http://www.jackaudio.org" @@ -55,6 +55,7 @@ $(use_enable sse) \ --with-html-dir=/usr/share/doc/${PF} \ --disable-dependency-tracking \ + --libdir=/usr/$(get_libdir) \ ${myconf} || die "configure failed" }