From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 177001391DB for ; Sun, 16 Mar 2014 11:50:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 751F5E0AED; Sun, 16 Mar 2014 11:50:35 +0000 (UTC) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 79149E0AC5 for ; Sun, 16 Mar 2014 11:50:34 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id cz12so4704293veb.30 for ; Sun, 16 Mar 2014 04:50:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=MfaxeiGkL8PmVfHqe8oIOLDRkHmJcsd4rGbNJpiThMI=; b=ElhVFO5qRRMlT9KBJ/9zfTODVGk27omBwp90HCcmeaBZZdISkkxBnJqF2NxoPP3BSY BaX1Jq1nzeqpX14lnVOdxyCgwYfqmpj+jqADCQbWuRo/BXj5XOaLVlZ7NkdDvsj7r902 bziMp2YnaeI+0wb2FrtrE6d9HmJs7teSLxaUOGaVXNM7QmCMRhSWAoR1SEYEtsqepxvR YLcRIBM2DfxCX2R715a5oHSW6/vCV/4eNE0khw/cpBV/QmVNp5ih/QHu3s1WDA0fwO82 wJCdmyPMfeshEnGQDFCNEV+khKWeVDe/q3HqZXMoVJOmkFaVcWMcyuS73u/m3DhHYx89 5org== X-Gm-Message-State: ALoCoQnG5mH+2Ag/ONFUaYiIjohnVXMJ+A3GwNSea+FbFS0PLIDTr3gGSW7uvyD1lulheXD6/QUg Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr2176261vcb.22.1394970633241; Sun, 16 Mar 2014 04:50:33 -0700 (PDT) Sender: gmt@be-evil.net Received: by 10.220.100.138 with HTTP; Sun, 16 Mar 2014 04:50:33 -0700 (PDT) X-Originating-IP: [75.147.143.254] In-Reply-To: <1394640392.7647.18.camel@rook> References: <53208139.2040509@gentoo.org> <1394640392.7647.18.camel@rook> Date: Sun, 16 Mar 2014 04:50:33 -0700 X-Google-Sender-Auth: roVL--RkELlzQpM4hbz7QJ0DhLY Message-ID: Subject: Re: [gentoo-dev] crossdev and multilib interference From: Greg Turner To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a11337576111fdf04f4b7e925 X-Archives-Salt: 611211b0-43ce-4e78-80cb-219b95d2f360 X-Archives-Hash: 9458d6ac436d3034da7dd8c735eb5c39 --001a11337576111fdf04f4b7e925 Content-Type: text/plain; charset=UTF-8 Just a few practical notes on this... On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev wrote: > > Now, SYSROOT is chosen from multiple conditions. When emerging a > > package, that happens to be "/" and thus results in: > > "//usr/lib/pkgconfig://usr/share/pkgconfig" > Bleh. This is where I obligatorily remind everyone that // != /. POSIX, cygwin, blahblahblah. In short, paths matching the regex "^//[^/]" are trouble, and will eventually force me to fix your code once I get back to gentoo-cygwin hacking. > > Build systems like autotools will pick the crossdev provided > > "i686-pc-linux-gnu-pkg-config" for the 32bit ABI which will in turn > > override the eclass-exported PKG_CONFIG_LIBDIR and now effectively > > find the pkg-config files in /usr/lib64/... > So do Gentoo's own toolchain*.eclasses, breaking many $(tc-getFOO) invocations in non-best multilib-build ABIS for which a matching crossdev target is installed (substituting ${FOO:-$(tc-getFOO)} works-around these problems in every instance I've seen; it probably wouldn't hurt to make such substitutions systematically, when multilib-utizing ebuilds and eclasses). > > This is not a problem most of the time if the package just wants to > > get the libs to link against > lots of "ignoring blahlib.so 'cause it's for the wrong ABI"-type warnings are a good sign your ebuild may have fallen into this rabbit-hole. > > > However, every package that tries to access variables that are > > different between /usr/lib32/pkgconfig/foo.pc and > > /usr/lib64/pkgconfig/foo.pc like "libdir" will fail or produce > > unexpected results. > > > > That already happens for > > x11-libs/libva-vdpau-driver > > x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=500338) > > > > and there are probably more. > "Every" might be too strong, but... yeah, tons. cmake-multilib.eclass, for example, breaks in mind-warpingly subtle and confusing ways on USE="abi_x86_{32,64}" multilib hosts with i686-pc-linux-gnu crossdev installed (when combined with some other issues in that eclass, this results in correct qawarns about ignored ldflags on devel profiles -- an ugly work-around is in my overlay, but I'm not happy with it, so it's been languishing in my rainy-day todo queue. I'd be thrilled to see a solution to the underlying problem, so I don't feel compelled to salvage the ugly parts). As for how to fix it, if foo-bar-baz-quux crossdev targets are at ${EROOT}/usr/foo-bar-baz-quux, putting wrappers in ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something like that, seems perfectly reasonable... heck, pure speculation, but it might even noticeably speed up day-to-day $PATH searching on systems with lots of crossdev targets installed. --001a11337576111fdf04f4b7e925 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a few practical notes on t= his...

O= n Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev <= tetromino@gentoo.= org> wrote:
>= Now, SYSROOT is chosen from multiple conditions. When emerging a
> package, that happens to be "/" and thus results in:
> =C2=A0 "//usr/lib/pkgconfig://usr/share/pkgconfig"
=

Bleh. =C2=A0This is where I obligatorily r= emind everyone that // !=3D /. POSIX, cygwin, blahblahblah. =C2=A0In short,= paths matching the regex "^//[^/]" are trouble, and will eventua= lly force me to fix your code once I get back to gentoo-cygwin hacking.
=C2=A0
> Build systems like autotools will pick the crossdev provided
> "i686-pc-linux-gnu-pkg-config" for the 32bit ABI which will = in turn
> override the eclass-exported PKG_CONFIG_LIBDIR and now effectively
> find the pkg-config files in /usr/lib64/...

So do Gentoo's own toolchain*.eclasses, breaking many $= (tc-getFOO) invocations in non-best multilib-build ABIS for which a matchin= g crossdev target is installed (substituting ${FOO:-$(tc-getFOO)} works-aro= und these problems in every instance I've seen; it probably wouldn'= t hurt to make such substitutions systematically, when multilib-utizing ebu= ilds and eclasses).
=C2=A0
> This is not a problem most of the time if the package just wants to > get the libs to link against

lot= s of "ignoring blahlib.so 'cause it's for the wrong ABI"-= type warnings are a good sign your ebuild may have fallen into this rabbit-= hole.
=C2=A0
=C2=A0
> However, every package that tries to access variables that are
> different between /usr/lib32/pkgconfig/foo.pc and
> /usr/lib64/pkgconfig/foo.pc like "libdir" will fail or produ= ce
> unexpected results.
>
> That already happens for
> x11-libs/libva-vdpau-driver
> x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=3D500338)
>
> and there are probably more.


=
cmake-multilib.eclass, for example, breaks in mind-warpingly subtle a= nd confusing ways on USE=3D"abi_x86_{32,64}" multilib hosts with = i686-pc-linux-gnu crossdev installed (when combined with some other issues = in that eclass, this results in correct qawarns about ignored ldflags on de= vel profiles -- an ugly work-around is in my overlay, but I'm not happy= with it, so it's been languishing in my rainy-day todo queue. =C2=A0I&= #39;d be thrilled to see a solution to the underlying problem, so I don'= ;t feel compelled to salvage the ugly parts).

As for how = to fix it, if foo-bar-baz-quux crossdev targets are at ${EROOT}/usr/foo-bar= -baz-quux, putting wrappers in ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers= , or something like that, seems perfectly reasonable... heck, pure speculat= ion, but it might even noticeably speed up day-to-day $PATH searching on sy= stems with lots of crossdev targets installed.
--001a11337576111fdf04f4b7e925--