From: Mike Frysinger <vapier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] crossdev and multilib interference
Date: Wed, 26 Mar 2014 01:17:14 -0400 [thread overview]
Message-ID: <1473612.xZUzGZodW8@vapier> (raw)
In-Reply-To: <20140313095502.73dc080b@pomiot.lan>
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
On Thu 13 Mar 2014 09:55:02 Michał Górny wrote:
> Dnia 2014-03-12, o godz. 15:46:01 hasufell napisał(a):
> > We have a problem where the crossdev pkg-config wrapper scripts
> > interfere with multilib.
> >
> > crossdev for example sets in their pkg-config wrappers:
> >
> > PKG_CONFIG_LIBDIR="${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgco
> > nfig"
> >
> > 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"
this behavior is more bug than feature. the preference is to utilize SYSROOT
in src_* functions first and ROOT in pkg_* functions. i'll have to see if
EBUILD_PHASE is exported to shell scripts ...
> > 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/...
> >
> > This is not a problem most of the time if the package just wants to
> > get the libs to link against.
> >
> > 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.
there have been reports dating back even longer. e.g. people used crossdev to
create i686-pc-linux-gnu and then tried to build sandbox. it's just the
number of people hitting this was fairly low (like ~1 a year). and for them,
it was possible to just use a diff tuple for their i686 compiler.
> Another possible workaround is to make pkgconfig true-multilib. Then it
> would own i686-pc-linux-gnu-pkgconfig, and that executable would work
> correctly. More than that, we could work on killing the PKG_CONFIG_PATH
> hack.
that by itself doesn't really help. the wrappers are designed to be used with
the respective cross-compiler (SYSROOT by default), not default to the host
system.
when you run `crossdev i686-pc-linux-gnu`, it owns that tuple. that includes
i686-pc-linux-gnu-pkg-config.
if we're going to have the multilib system lie and use a tuple that doesn't
actually exist, we either:
(1) override all the vars so they point back to the real toolchain.
this doesn't scale when you consider helper tools like the legacy sdl-config
or the extended set of tools that binutils/gcc/etc... install. it's mitigated
by the fact the set of vars in play most of the time is low.
(2) use tuples with loaded vendor fields to reduce the chance of collisions.
e.g. having an ABI=amd64 system use i686-gentoo%multilib-linux-gnu instead of
i686-pc-linux-gnu would defeat any automatic path searches.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-03-26 5:17 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 15:46 [gentoo-dev] crossdev and multilib interference hasufell
2014-03-12 16:06 ` Alexandre Rostovtsev
2014-03-12 18:56 ` Alexis Ballier
2014-03-16 11:50 ` Greg Turner
2014-03-26 6:07 ` Mike Frysinger
2014-03-26 12:25 ` [gentoo-dev] " Steven J. Long
2014-03-26 16:12 ` Mike Frysinger
2014-03-26 16:23 ` Ian Stakenvicius
2014-03-27 2:41 ` Mike Frysinger
2014-03-27 4:41 ` Alexandre Rostovtsev
2014-03-27 6:07 ` Mike Frysinger
2014-03-27 6:31 ` Alexandre Rostovtsev
2014-03-27 6:41 ` Mike Frysinger
2014-03-27 6:51 ` Michał Górny
2014-03-27 7:23 ` Mike Frysinger
2014-03-27 6:58 ` Samuli Suominen
2014-03-27 8:41 ` [gentoo-dev] " Steven J. Long
2014-03-28 6:36 ` Mike Frysinger
2014-03-30 9:53 ` [gentoo-dev] " Steven J. Long
2014-06-15 20:35 ` hasufell
2014-06-15 20:43 ` Chí-Thanh Christopher Nguyễn
2014-06-16 13:37 ` hasufell
2014-06-16 18:42 ` Steev Klimaszewski
2014-06-16 19:31 ` hasufell
2014-06-16 19:42 ` Jeroen Roovers
2014-06-16 19:47 ` hasufell
2014-06-16 20:05 ` Joshua Kinard
2014-06-16 20:24 ` hasufell
2014-06-16 20:59 ` Joshua Kinard
2014-06-16 22:10 ` hasufell
2014-06-16 23:38 ` Joshua Kinard
2014-06-17 1:47 ` hasufell
2014-06-17 2:17 ` Joshua Kinard
2014-06-17 12:30 ` hasufell
2014-06-17 12:49 ` Rich Freeman
2014-06-17 13:53 ` hasufell
2014-06-17 14:17 ` Joshua Kinard
2014-06-17 14:56 ` Alexandre Rostovtsev
2014-06-17 15:10 ` Michał Górny
2014-06-18 15:24 ` Peter Stuge
2014-06-19 7:58 ` Michał Górny
2014-06-17 15:20 ` Joshua Kinard
2014-06-18 5:08 ` Alexandre Rostovtsev
2014-06-18 6:24 ` Joshua Kinard
2014-06-18 14:18 ` Ian Stakenvicius
2014-06-19 21:20 ` [gentoo-dev] " Steven J. Long
2014-06-20 20:10 ` [gentoo-dev] " Ian Stakenvicius
2014-06-21 10:31 ` Greg Turner
2014-06-21 20:47 ` Michał Górny
2014-08-01 9:05 ` Steven J. Long
2014-08-01 14:36 ` Ian Stakenvicius
2014-08-01 18:17 ` [gentoo-dev] " Steven J. Long
2014-06-18 4:29 ` [gentoo-dev] " Ryan Hill
2014-06-17 14:04 ` [gentoo-dev] Re: " Joshua Kinard
2014-06-17 14:38 ` hasufell
2014-06-17 15:02 ` Joshua Kinard
2014-06-17 15:18 ` hasufell
2014-06-17 15:37 ` hasufell
2014-06-17 12:48 ` hasufell
2014-06-17 14:31 ` Joshua Kinard
2014-06-17 13:25 ` Ian Stakenvicius
2014-06-17 14:22 ` Michał Górny
2014-06-17 14:34 ` Joshua Kinard
2014-06-16 23:25 ` Patrick Lauer
2014-06-16 20:27 ` Ian Stakenvicius
2014-06-16 21:42 ` [gentoo-dev] " Jeroen Roovers
2014-06-17 0:03 ` Joshua Kinard
2014-06-16 20:25 ` [gentoo-dev] Re: Re: " hasufell
2014-06-16 2:24 ` [gentoo-dev] " Ryan Hill
2014-06-16 13:27 ` hasufell
2014-06-17 4:52 ` Ryan Hill
2014-06-17 12:29 ` hasufell
2014-03-29 1:21 ` [gentoo-dev] " Maciej Mrozowski
2014-03-16 12:01 ` Greg Turner
2014-03-13 8:55 ` Michał Górny
2014-03-13 12:20 ` Alexandre Rostovtsev
2014-03-26 5:17 ` Mike Frysinger [this message]
2014-03-27 6:13 ` Mike Frysinger
2014-03-27 6:51 ` Michał Górny
2014-03-27 7:18 ` Mike Frysinger
2014-03-27 9:10 ` Michał Górny
2014-03-27 14:23 ` Mike Frysinger
2014-03-27 14:31 ` Michał Górny
2014-03-28 6:33 ` Mike Frysinger
2014-03-29 21:39 ` Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1473612.xZUzGZodW8@vapier \
--to=vapier@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox