Bug 466732 – media-sound/jack-audio-connection-kit: does not install its DSO's into LIBDIR

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Anthony Basile 2013-04-21 21:51:19 UTC]

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"
 }

[Comment 1 Alexis Ballier 2013-04-22 08:06:23 UTC]

wait, isnt econf supposed to do this already ?

[Comment 2 Anthony Basile 2013-04-22 08:24:30 UTC]

(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.

[Comment 3 Alexis Ballier 2013-04-22 08:28:13 UTC]

(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.

[Comment 4 Zac Medico 2013-04-22 08:39:58 UTC]

(In reply to comment #3)
Sounds like bug 239190.

[Comment 5 Anthony Basile 2013-04-22 09:57:08 UTC]

(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.)

[Comment 6 Zac Medico 2013-04-22 16:03:33 UTC]

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.

[Comment 7 SpanKY 2013-04-23 00:06:33 UTC]

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

[Comment 8 Anthony Basile 2013-05-12 12:37:59 UTC]

(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?

[Comment 9 Alexis Ballier 2013-05-12 15:02:47 UTC]

(In reply to comment #8)

I don't particularly like it but feel free to commit