Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

[gentoo-dev] crossdev and multilib interference

166 views
Skip to first unread message

hasufell

unread,
Mar 12, 2014, 11:50:01 AM3/12/14
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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/pkgconfig"

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"

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.

A simple workaround is:
PKG_CONFIG="pkg-config" emerge foo

But I think that is not appropriate to set in the eclass. How can we
solve this? Don't bikeshed.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTIIE5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgLvMQALJT5uZFBTL5mHNBjezudMHo
ceHY3TzLfeIkWHedCLU9TAapfLjl677W0jbg25zkLayPtUR3voEAIm6xFZtF2CAS
VsBpArieXQWqtxSrT9hHC1dJeAWQvQs1kyKXBb5ido8sEBb7WpHFlEqwmUY5bn33
TZjGjcQ68EojbcFQl0vmJRx1/bgXxOr9Ir4Y1bFX92S9ENhERnisu3zZrcvC+PyH
XqXg+wFoJfxu1fSL4/llRDfyr0UJWlWdMeCpvwgkhCpn66CBwc50BwokMP4f4x3G
YDbi+1Ep4GIBVHLd5MlfZOkeqhzPQRD10lbnOHmW7Wuh6Mu87UI7G9xHWZcNyEkS
U9Ny0ejyqnx0j5TMgMP/IcpBR1PaRcceTLFYhwJrYucgcB6/YZ1sP81Yce7f2Riy
M6OZontsv8GVbPA4tsgsV4wob6XUzn6d47p4jwbq67u3GUX6QU7fNB0yJ2ga56qV
xvIaEgdOFsAZHOyix6zfTa2AqpE2LQiVfwEF2pI4J4bTCfy7DvfWhuvA5IwWyyFA
jPiGr5xEns85v2q+dagUo/iup9gzbgGQs+dH6w3wXTkip72lnbxHwiz8Pa2eIXVl
+Tvo9vcdVSzw68tF30sS005+HNorCkj/pqdC7FND/KCyC7r3aESmagibqKdUhHPc
9sN1RjgyzXYst5mvQ1Hg
=J4Qp
-----END PGP SIGNATURE-----

Alexandre Rostovtsev

unread,
Mar 12, 2014, 12:10:03 PM3/12/14
to
Two possibilities:
1. Don't allow crossdev to handle targets which are natively handled by
multilib profiles. For example, is there any legitimate reason for
wanting crossdev's i686 wrappers when on a multilib amd64 profile?
2. Have crossdev install its wrappers in a prefix, for example
in /usr/libexec/crossdev, which gets added to PATH by cross-emerge.
signature.asc

Alexis Ballier

unread,
Mar 12, 2014, 3:00:02 PM3/12/14
to
On Wed, 12 Mar 2014 12:06:32 -0400
Alexandre Rostovtsev <tetr...@gentoo.org> wrote:

> Two possibilities:
> 1. Don't allow crossdev to handle targets which are natively handled
> by multilib profiles. For example, is there any legitimate reason for
> wanting crossdev's i686 wrappers when on a multilib amd64 profile?

yes, serving as a distcc server for x86 hosts or using 'cross emerge'
to build a x86 root from scratch

> 2. Have crossdev install its wrappers in a prefix, for example
> in /usr/libexec/crossdev, which gets added to PATH by cross-emerge.

lgtm

Michał Górny

unread,
Mar 13, 2014, 5:00:02 AM3/13/14
to
Dnia 2014-03-12, o godz. 15:46:01
hasufell <hasu...@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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/pkgconfig"
>
> 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"
>
> 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.

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.

--
Best regards,
Michał Górny
signature.asc

Alexandre Rostovtsev

unread,
Mar 13, 2014, 8:30:02 AM3/13/14
to
That won't work with current versions of crossdev because they blindly
create/delete their pkg-config wrappers without checking if they are
overwriting or removing something that belongs to another package.
signature.asc

Greg Turner

unread,
Mar 16, 2014, 8:00:02 AM3/16/14
to
Just a few practical notes on this...

On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev <tetr...@gentoo.org> 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.

Greg Turner

unread,
Mar 16, 2014, 8:10:02 AM3/16/14
to
On Wed, Mar 12, 2014 at 9:06 AM, Alexandre Rostovtsev <tetr...@gentoo.org> wrote:
is there any legitimate reason for
wanting crossdev's i686 wrappers when on a multilib amd64 profile?

One other note: legitimacy is in the eye of the legitimizer, I suppose, but there are sometimes practical reasons to want a no-multilib compiler.

A trivial example is that some primitive build scripts go ape when CC has a space in it (but this is certainly debatable as to its legitimacy, given the obvious work-arounds).

Mike Frysinger

unread,
Mar 26, 2014, 1:20:01 AM3/26/14
to
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
signature.asc

Mike Frysinger

unread,
Mar 26, 2014, 2:10:01 AM3/26/14
to
On Sun 16 Mar 2014 04:50:33 Greg Turner wrote:
> 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).

cmake is completely broken when it comes to library searching and multilib and
cross-compiling. it will happily look in hardcoded / paths to test for the
existence of files as well as directly execute `pkg-config`. it's a great
example of people saying "autotools is crap, so let's invent our own kind of
crap and ignore lessons learned". this isn't the fault of cmake eclasses, but
it'd be nice if we could someone standardize the hacks in there so we don't
have to duplicate across ebuilds.

just look at how cmake internally utilizes CMAKE_FIND_ROOT_PATH. or grep
"pkg-config" in /usr/share/cmake/. or look at find_library usage in cmake
macros. it's fundamentally screwed up right now :(.

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

if they're in $PATH, then the exact location is irrelevant. they need not be
in /usr/bin to cause a problem. if they're not in $PATH, then you're breaking
the cross-compilers and that is unacceptable.

putting CHOST things in /usr/CTARGET is incorrect. /usr/CHOST/CTARGET/ is for
hosting helper programs specific to CTARGET that run on CHOST.
-mike
signature.asc

Steven J. Long

unread,
Mar 26, 2014, 8:10:04 AM3/26/14
to
Mike Frysinger wrote:
> Greg Turner wrote:
> > 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.
>
> if they're in $PATH, then the exact location is irrelevant.
> they need not be in /usr/bin to cause a problem.
> if they're not in $PATH, then you're breaking the cross-compilers
> and that is unacceptable.

Cross-compilation should be supported via cross-emerge, and perhaps a small
script the cross-compiler sources to setup the env (ie prefix to PATH in
this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting
a straight x86 platform, instead of the normal multilib setup. The
latter being used by the former (I'd have thought it was already done.)

The cross tools should NOT pollute the default PATH, simply because the
user happened to run crossdev at some point. It's *borked*, plain and
simple, so fix it please or expect people to come up with other solutions
[1]; fragmenting the effort, and making cross-compilers lives harder, as
we try to blend together a working solution from various efforts. The
exact thing crossdev is supposed to answer.

> putting CHOST things in /usr/CTARGET is incorrect. /usr/CHOST/CTARGET/
> is for hosting helper programs specific to CTARGET that run on CHOST.

Great, make it part of the env script. Though CHOST is usually the "target"
for most packages, so not sure of the relevance apart from toolchain.
Greg appeared to be saying use /usr/CHOST/usr/bin/gcc for example (istr
it's effectively a root under there) or just prefix the relevant bindirs
to PATH, along with whatever other voodoo you need. sed for instance is
still going to come from native CBUILD /bin.

Regards,
steveL

[1] https://github.com/chewi/cross-boss [still in preview]
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Mike Frysinger

unread,
Mar 26, 2014, 12:20:02 PM3/26/14
to
On Wed 26 Mar 2014 12:25:29 Steven J. Long wrote:
> Mike Frysinger wrote:
> > Greg Turner wrote:
> > > 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.
> >
> > if they're in $PATH, then the exact location is irrelevant.
> > they need not be in /usr/bin to cause a problem.
> > if they're not in $PATH, then you're breaking the cross-compilers
> > and that is unacceptable.
>
> Cross-compilation should be supported via cross-emerge, and perhaps a small
> script the cross-compiler sources to setup the env (ie prefix to PATH in
> this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting
> a straight x86 platform, instead of the normal multilib setup. The
> latter being used by the former (I'd have thought it was already done.)
>
> The cross tools should NOT pollute the default PATH, simply because the
> user happened to run crossdev at some point. It's *borked*, plain and
> simple, so fix it please or expect people to come up with other solutions
> [1]; fragmenting the effort, and making cross-compilers lives harder, as
> we try to blend together a working solution from various efforts. The
> exact thing crossdev is supposed to answer.

that's bs. people install crossdev to get a cross-compile environment, not to
get something that only works through `emerge`. attempting to restrict it so
it only works through `emerge` is unacceptable and it has never been that way.
-mike
signature.asc

Ian Stakenvicius

unread,
Mar 26, 2014, 12:30:02 PM3/26/14
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
it -does- make sense though to limit anything that one wants to EMERGE
with the crossdev, to require the use of cross-emerge. Would it not
be possible to somehow ensure the crossdev tools are ignored
in/removed from/cannot pollute the standard emerge environment? Are
there any use cases where one -would- want the crossdev to be used in
a standard emerge environment instead of using cross-emerge ?




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMy/xkACgkQ2ugaI38ACPClAAD/bwSIWjCu32eDlf3faqnqhvc3
94JxKfSwY3pPv7X4A68A/1g8KSov5e/BHGYXyhlyCd8j3Bc+IukxoNYMXiXiluh7
=TMGw
-----END PGP SIGNATURE-----

Mike Frysinger

unread,
Mar 26, 2014, 10:50:02 PM3/26/14
to
On Wed 26 Mar 2014 12:23:53 Ian Stakenvicius wrote:
> On 26/03/14 12:12 PM, Mike Frysinger wrote:
> > that's bs. people install crossdev to get a cross-compile
> > environment, not to get something that only works through `emerge`.
> > attempting to restrict it so it only works through `emerge` is
> > unacceptable and it has never been that way.
>
> it -does- make sense though to limit anything that one wants to EMERGE
> with the crossdev, to require the use of cross-emerge. Would it not
> be possible to somehow ensure the crossdev tools are ignored
> in/removed from/cannot pollute the standard emerge environment? Are
> there any use cases where one -would- want the crossdev to be used in
> a standard emerge environment instead of using cross-emerge ?

you've lost me. when you `emerge-$CTARGET`, that package doesn't go anywhere
near your ROOT=/ system. it's entirely contained in /usr/$CTARGET/.

when you run `crossdev $CTARGET`, it installs all the standard $CTARGET-xxx
tools in /usr/bin. this isn't "polluting" the environment at all ... in fact,
they're living right alongside existing tools.

as i pointed out elsewhere in this thread, the problem is that multilib relies
on automatic detection of the toolchain *failing* so that it falls back to the
native value. in other words, when you run `./configure --host=i686-pc-linux-
gnu`, it tries to find e.g. i686-pc-linux-gnu-ar. it doesn't exist so the
fallback is used (plain `ar`). multilib is using these tuples so that the
standard checks (autoconf/eclasses/etc...) trigger in the right ways for the
cpu/os/userland combinations.

since crossdev installs a full proper toolchain for the target, the one
multilib was using to lie now exists and its toolchain is used instead.
-mike
signature.asc

Alexandre Rostovtsev

unread,
Mar 27, 2014, 12:50:01 AM3/27/14
to
Crossdev is "polluting the environment" in the specific case that we are
talking about - secondary native ABIs on a multilib system.

An amd64 multilib system is not expected to build MIPS binaries that
would be hosted on itself. So of course anyone using amd64 undersands
that mips-pc-linux-gnu-ar is part of a cross-compile toolchain, no
matter whether it's in /usr/bin or /usr/libexec/crossdev or anywhere in
the filesystem.

However, an i686 crossdev on an amd64 multilib system is a fundamentally
different situation. An amd64 multilib system *is* expected to build x86
binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
expected to be not a part of any cross-compile toolchain, but a part of
the native toolchain for the machine's secondary native ABI. Especially
when i686-pc-linux-gnu-ar is in /usr/bin.
signature.asc

Mike Frysinger

unread,
Mar 27, 2014, 2:10:01 AM3/27/14
to
> Crossdev is "polluting the environment" in the specific case that we are
> talking about - secondary native ABIs on a multilib system.
>
> An amd64 multilib system is not expected to build MIPS binaries that
> would be hosted on itself. So of course anyone using amd64 undersands
> that mips-pc-linux-gnu-ar is part of a cross-compile toolchain, no
> matter whether it's in /usr/bin or /usr/libexec/crossdev or anywhere in
> the filesystem.
>
> However, an i686 crossdev on an amd64 multilib system is a fundamentally
> different situation.

no, it is not

> An amd64 multilib system *is* expected to build x86
> binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
> expected to be not a part of any cross-compile toolchain, but a part of
> the native toolchain for the machine's secondary native ABI. Especially
> when i686-pc-linux-gnu-ar is in /usr/bin.

sure, and it works just fine when you use the correct toolchain. if the user
wants to build an ABI using their default toolchain, they can pass the right
ABI flag for it.

but that's irrelevant to how our multilib implementation picks its fake
CHOST_$ABI to take care of implementing things. if anything, the current
system is provably broken because the default ends up executing unqualified
`ar` and `ranlib` friends.
-mike
signature.asc

Mike Frysinger

unread,
Mar 27, 2014, 2:20:02 AM3/27/14
to
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> (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.

this patch keeps the status quo. although the status quo is broken, but we
can sort that out independently.
-mike

--- profiles/arch/amd64/make.defaults 18 Jan 2014 01:03:24 -0000 1.21
+++ profiles/arch/amd64/make.defaults 27 Mar 2014 06:13:22 -0000
@@ -21,17 +21,17 @@ ABI="amd64"
# 64bit specific settings.
CFLAGS_amd64="-m64"
LDFLAGS_amd64="-m elf_x86_64"
-CHOST_amd64="x86_64-pc-linux-gnu"
+CHOST_amd64="${CHOST}"

# 32bit specific settings.
CFLAGS_x86="-m32"
LDFLAGS_x86="-m elf_i386"
-CHOST_x86="i686-pc-linux-gnu"
+CHOST_x86="i686-gentoo%multilib-linux-gnu"

# 64-32bit specific settings.
CFLAGS_x32="-mx32"
LDFLAGS_x32="-m elf32_x86_64"
-CHOST_x32="x86_64-pc-linux-gnux32"
+CHOST_x32="x86_64-gentoo%multilib-linux-gnux32"

# 2006/10/24 - Simon Stelling <bl...@gentoo.org>
# They are masked, but we can enable them anyway for those who have
signature.asc

Alexandre Rostovtsev

unread,
Mar 27, 2014, 2:40:01 AM3/27/14
to
On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote:
> > An amd64 multilib system *is* expected to build x86
> > binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
> > expected to be not a part of any cross-compile toolchain, but a part of
> > the native toolchain for the machine's secondary native ABI. Especially
> > when i686-pc-linux-gnu-ar is in /usr/bin.
>
> sure, and it works just fine when you use the correct toolchain. if the user
> wants to build an ABI using their default toolchain, they can pass the right
> ABI flag for it.

They can't pass the right ABI flag because only the core parts of the
toolchain have the concept of an ABI flag.

Sure, binutils and gcc respect "-m32". But what about pkgconfig (and its
clones pkgconf and pkgconfig-openbsd)? What about the *-config tools for
various libraries? Are you going to patch all of them to respect "-m32"?
signature.asc

Mike Frysinger

unread,
Mar 27, 2014, 2:50:01 AM3/27/14
to
pkg-config does need fixing in some way. we already know this. it's why the
multilib eclasses currently set PKG_CONFIG_XXX vars -- preciously so the
correct ABI dir is utilized. and this breaks when using some build systems
(like scons) where the env gets blown away (although we also know scons
sucks).

i don't care about the *-config scripts. that's a dead concept long ago
proven to suck and anything still using it needs fixing.
-mike
signature.asc

Michał Górny

unread,
Mar 27, 2014, 3:00:01 AM3/27/14
to
Dnia 2014-03-27, o godz. 02:41:21
Mike Frysinger <vap...@gentoo.org> napisał(a):
Because it's everyone else that *always* does something wrong,
and the rising number of work-arounds in the eclass just proves you're
doing it the correct way.

It's sad that decisions are made by man who *does not care* about most
of the real-life things but cares much for his own precious tools that
get priority over eclasses, and whenever they are essentially broken
by design, you say that the world is actually broken and they
are the only fine thing.
signature.asc

Michał Górny

unread,
Mar 27, 2014, 3:00:01 AM3/27/14
to
Dnia 2014-03-27, o godz. 02:13:52
Mike Frysinger <vap...@gentoo.org> napisał(a):

> On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > (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.
>
> this patch keeps the status quo. although the status quo is broken, but we
> can sort that out independently.

Except that it breaks stuff that is installed at the point and comes
with no plan of cleaning up the resulting mess.

> --- profiles/arch/amd64/make.defaults 18 Jan 2014 01:03:24 -0000 1.21
> +++ profiles/arch/amd64/make.defaults 27 Mar 2014 06:13:22 -0000
> @@ -21,17 +21,17 @@ ABI="amd64"
> # 64bit specific settings.
> CFLAGS_amd64="-m64"
> LDFLAGS_amd64="-m elf_x86_64"
> -CHOST_amd64="x86_64-pc-linux-gnu"
> +CHOST_amd64="${CHOST}"
>
> # 32bit specific settings.
> CFLAGS_x86="-m32"
> LDFLAGS_x86="-m elf_i386"
> -CHOST_x86="i686-pc-linux-gnu"
> +CHOST_x86="i686-gentoo%multilib-linux-gnu"

Using percent sign here looks like asking for trouble at some point.
I don't see why you can't use plain 'gentoomultilib' that is more
fool-proof.

> # 64-32bit specific settings.
> CFLAGS_x32="-mx32"
> LDFLAGS_x32="-m elf32_x86_64"
> -CHOST_x32="x86_64-pc-linux-gnux32"
> +CHOST_x32="x86_64-gentoo%multilib-linux-gnux32"
>
> # 2006/10/24 - Simon Stelling <bl...@gentoo.org>
> # They are masked, but we can enable them anyway for those who have



signature.asc

Samuli Suominen

unread,
Mar 27, 2014, 3:10:01 AM3/27/14
to
I pushed 0.28-r1 of dev-util/pkgconfig with ABI_X86 support so that you
can directly
call eg. i686-pc-linux-gnu-pkg-config to search from /usr/lib32/pkgconfig/

I'll try to figure something out for pkgconfig-openbsd too. Don't care
about pkgconf.

> i don't care about the *-config scripts. that's a dead concept long ago
> proven to suck and anything still using it needs fixing.
>

nod

Mike Frysinger

unread,
Mar 27, 2014, 3:20:02 AM3/27/14
to
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
> Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > (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.
> >
> > this patch keeps the status quo. although the status quo is broken, but
> > we
> > can sort that out independently.
>
> Except that it breaks stuff that is installed at the point and comes
> with no plan of cleaning up the resulting mess.

such as ... ? vague statements can't be addressed.

> > --- profiles/arch/amd64/make.defaults 18 Jan 2014 01:03:24 -0000 1.21
> > +++ profiles/arch/amd64/make.defaults 27 Mar 2014 06:13:22 -0000
> > @@ -21,17 +21,17 @@ ABI="amd64"
> >
> > # 64bit specific settings.
> > CFLAGS_amd64="-m64"
> > LDFLAGS_amd64="-m elf_x86_64"
> >
> > -CHOST_amd64="x86_64-pc-linux-gnu"
> > +CHOST_amd64="${CHOST}"
> >
> > # 32bit specific settings.
> > CFLAGS_x86="-m32"
> > LDFLAGS_x86="-m elf_i386"
> >
> > -CHOST_x86="i686-pc-linux-gnu"
> > +CHOST_x86="i686-gentoo%multilib-linux-gnu"
>
> Using percent sign here looks like asking for trouble at some point.
> I don't see why you can't use plain 'gentoomultilib' that is more
> fool-proof.

i merely picked a value that was highly unlikely for people to use. the %
should be safe as it is not interpreted by the shell and strongly indicates
"hey man, don't mess with me". it could just as easily be a _ or nothing at
all. i don't feel strongly about it.
-mike
signature.asc

Mike Frysinger

unread,
Mar 27, 2014, 3:30:02 AM3/27/14
to
really have no idea what you're ranting about. doesn't look discussion worthy
though.
-mike
signature.asc

Steven J. Long

unread,
Mar 27, 2014, 4:30:02 AM3/27/14
to
Mike Frysinger wrote:
> Steven J. Long wrote:
> > Mike Frysinger wrote:
> > > if they're in $PATH, then the exact location is irrelevant.
> > > they need not be in /usr/bin to cause a problem.
> > > if they're not in $PATH, then you're breaking the cross-compilers
> > > and that is unacceptable.
> >
> > Cross-compilation should be supported via cross-emerge, and perhaps a small
> > script the cross-compiler sources to setup the env (ie prefix to PATH in
> > this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting
> > a straight x86 platform, instead of the normal multilib setup. The
> > latter being used by the former (I'd have thought it was already done.)
> >
> > The cross tools should NOT pollute the default PATH, simply because the
> > user happened to run crossdev at some point.

> that's bs. people install crossdev to get a cross-compile environment, not to
> get something that only works through `emerge`. attempting to restrict it so
> it only works through `emerge` is unacceptable and it has never been that way.

That's why I suggested a small sh script to source, to setup that environment.
Personally, I do an awful lot more than that just to build a native chroot,
let alone cross-compile. And I really don't see the hardship for these brave
"cross-compilers" of yours in sourcing a small setup script, which can be
added to ~/.bashrc or even the system-wide one, for anyone who really wants
it to apply whenever they login. Is this somehow beyond our most advanced
userbase?

People may install crossdev to get a cross-compile environment, but it's a
broken design if it's not contained. And BS about how you think it should
ALWAYS go for everybody, only leads to borked "solutions" elsewhere like
telling the people on an amd64 install that they have to run some god-awful
"new" %multilib thing to compile for their secondary ABI. That's just as
counter-intuitive, when you could just fix your borkage and have a clean
setup for everyone.

Michał Górny

unread,
Mar 27, 2014, 5:20:02 AM3/27/14
to
Dnia 2014-03-27, o godz. 03:18:31
Mike Frysinger <vap...@gentoo.org> napisał(a):

> On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
> > Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > > (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.
> > >
> > > this patch keeps the status quo. although the status quo is broken, but
> > > we
> > > can sort that out independently.
> >
> > Except that it breaks stuff that is installed at the point and comes
> > with no plan of cleaning up the resulting mess.
>
> such as ... ? vague statements can't be addressed.

Such as all the builds that use ${CHOST}-foo currently. If you change
CHOST, our users will have to find and rebuild all packages that
install ${CHOST}-foos or otherwise random breakage will happen.
signature.asc

Mike Frysinger

unread,
Mar 27, 2014, 10:30:01 AM3/27/14
to
On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
again, please give a concrete example
-mike
signature.asc

Michał Górny

unread,
Mar 27, 2014, 10:40:02 AM3/27/14
to
Dnia 2014-03-27, o godz. 10:23:30
Mike Frysinger <vap...@gentoo.org> napisał(a):
glib -- ${CHOST}-gdk-pixbuf-query-loaders (used in gnome2-utils.eclass)
gpg-error -- ${CHOST}-gpg-error-config
libgcrypt -- ${CHOST}-libgcrypt-config
llvm -- ${CHOST}-llvm-config
pango -- ${CHOST}-pango-querymodules

If you change CHOST, all invocations of those tools will fail randomly
until the respective packages are rebuilt. In some cases it will call
the wrong variant (resulting in borked output), in other it will call
non-existing tool.

And let's just hope it's the only issue we're going to hit.
signature.asc

Mike Frysinger

unread,
Mar 28, 2014, 2:40:02 AM3/28/14
to
On Thu 27 Mar 2014 15:31:31 Michał Górny wrote:
so the *-config scripts. we already know these are broken, not only from a
conceptual pov, but from real world too -- it relies on CHOST being unique.
but this needs to be sorted out anyways since the current system isn't working
(independent of crossdev usage), and perhaps that means breaking now so things
are cleaner in the future.

for the gnupg projects, we've already disabled -L paths from being emitted, so
the variants will still work (gpg-error-config will give the same answer as
$CHOST-gpg-error-config wrt --libs and such).

the llvm/gdk/pango logic would probably break. we had been looking at
rewriting the gdk/pango stuff to not require direct execution (since this
logic completely fails when cross-compiling) in Chromium OS, but that's been
on the back burner for a while. instead, we hand generate/mung the pango
modules cache file, and we've punted gtk/gdk from the image, so we don't care
it is broken.

the pango stuff is also broken because it uses /etc/pango/$CHOST in an attempt
to get an ABI unique path. we probably should change that to /etc/pango/$ABI
or /etc/pango/$(get_libdir) or move it the multilib dir like the gdk cache
does. the gnome guys would know best.

the llvm impact doesn't look terribly big as very few things use it.
-mike
signature.asc

Mike Frysinger

unread,
Mar 28, 2014, 2:40:02 AM3/28/14
to
your conclusions are invalid as you're basing them on the assumption that the
current multilib system is working correctly and cleanly. it is provably not.

sticking your head in the sand and blaming crossdev for errors in the multilib
logic is asinine.
-mike
signature.asc

Maciej Mrozowski

unread,
Mar 28, 2014, 9:30:02 PM3/28/14
to
On Wednesday 26 of March 2014 02:07:56 Mike Frysinger wrote:

| cmake is completely broken when it comes to library searching and multilib and
| cross-compiling. it will happily look in hardcoded / paths to test for the
| existence of files as well as directly execute `pkg-config`. it's a great
| example of people saying "autotools is crap, so let's invent our own kind of
| crap and ignore lessons learned". this isn't the fault of cmake eclasses, but
| it'd be nice if we could someone standardize the hacks in there so we don't
| have to duplicate across ebuilds.

If we provided toolchain.cmake (passed to CMake via -DCMAKE_TOOLCHAIN_FILE=<path>) file for each crossdev, that could not only set compiler paths/etc but also override CMAKE_SYSTEM_PREFIX_PATH, we would get pretty close to autotools.

Yes, CMake has pretty rudimentary (to put it mildly..) cross-compilation support but it still can be done there somewhat "right".

regards
MM
signature.asc

Michał Górny

unread,
Mar 29, 2014, 5:40:02 PM3/29/14
to
Dnia 2014-03-28, o godz. 02:33:09
Mike Frysinger <vap...@gentoo.org> napisał(a):

> the pango stuff is also broken because it uses /etc/pango/$CHOST in an attempt
> to get an ABI unique path. we probably should change that to /etc/pango/$ABI
> or /etc/pango/$(get_libdir) or move it the multilib dir like the gdk cache
> does. the gnome guys would know best.

Because inventing distro-specific directories is always the best
solution.

> the llvm impact doesn't look terribly big as very few things use it.

Indeed, most of Gentoo amd64 users don't care about being unable to
build Mesa at all.
signature.asc

Steven J. Long

unread,
Mar 30, 2014, 5:40:01 AM3/30/14
to
Mike Frysinger wrote:
> Steven J. Long wrote:
> > Mike Frysinger wrote:
> > > Steven J. Long wrote:
> > > > The cross tools should NOT pollute the default PATH, simply because the
> > > > user happened to run crossdev at some point.
> > >
> > > that's bs. people install crossdev to get a cross-compile environment,
> > > not to get something that only works through `emerge`. attempting to
> > > restrict it so it only works through `emerge` is unacceptable and it has
> > > never been that way.
> >
> > That's why I suggested a small sh script to source, to setup that
> > environment. Personally, I do an awful lot more than that just to build a
> > native chroot, let alone cross-compile. And I really don't see the hardship
> > for these brave "cross-compilers" of yours in sourcing a small setup
> > script, which can be added to ~/.bashrc or even the system-wide one, for
> > anyone who really wants it to apply whenever they login. Is this somehow
> > beyond our most advanced userbase?
> >
> > People may install crossdev to get a cross-compile environment, but it's a
> > broken design if it's not contained.
>
> your conclusions are invalid as you're basing them on the assumption that
> the current multilib system is working correctly and cleanly.

No, I am not. I am basing them on the premise that a "target" SYSROOT is
potentially only one of N such sysroots for the same config.guess stanza.
I expected you to see that usage immediately, and the flexibility that
separation brings. After all, crossdev separates sysroots out already. It's
a trivial change to keep them separate, and it's easy for cross-compilers,
who already deal with this kind of thing, and more, on a daily basis. Only
it gives them more options should they want them, as I for one do.

No, use-cases are not relevant at this point. If you can't see it, that
doesn't meant it's not out there; it just means you're looking in the
wrong direction.

> it is provably not.
>
> sticking your head in the sand and blaming crossdev for errors in the
> multilib logic is asinine.

And sticking your head in the sand and ignoring flexibility, is simply your
usual ego-waving (as well as providing amusement at your rationalisation-
masquerading-as-logic.) I'd hoped you'd grown past this in the last few years,
since the embarrassing (to you) eclass-manpages awk bug, but evidently not.
It's why you're an awful recruiter, and imo a useless coder, despite being
a very talented QA person and bug-patcher.

The more you code, the more you have to realise how susceptible you are to
mistake. It's *after* you fully realise and _accept_ that, that you become
a truly useful coder. You are clearly still at the wrestling-with-the-ego
stage, after all these years. So you have my sympathy, because I know how
difficult a fight that is, and you're clearly in distress (or you wouldn't
resort to negative personal attacks so frequently, instead of considering
the application. So much bile..) The way to win is to stop fighting,
because you are only fighting yourself.

Accept that you are only a human, and you make mistakes and have blind-spots
just like everyone else. One's just been pointed out to you; do you do the
grown-up thing and accept that, and fix it, or do you keep on with the
tantrums, the dodgy patches and the baroque chain of "fixes" that flow from
your borked "logic"? Grow up, already. Or fire off more bile > /dev/null.

"I'll see you when you get there, if you ever get there.."

hasufell

unread,
Jun 15, 2014, 4:40:01 PM6/15/14
to
Steven J. Long:
>
> "I'll see you when you get there, if you ever get there.."
>

No improvements so far. I am going to hardmask sys-devel/crossdev,
unless someone can explain why we are still in broken stage.

More packages are popping up that randomly break. Recent failures were
related to tc-getBUILD_CC.

This isn't stable in any way. I'm not blaming anyone, but that's what
hardmasking is for. A working solution was declined, so...

Chí-Thanh Christopher Nguyễn

unread,
Jun 15, 2014, 4:50:03 PM6/15/14
to
hasufell schrieb:
> No improvements so far. I am going to hardmask sys-devel/crossdev,
> unless someone can explain why we are still in broken stage.
>
> More packages are popping up that randomly break. Recent failures were
> related to tc-getBUILD_CC.
>
> This isn't stable in any way. I'm not blaming anyone, but that's what
> hardmasking is for. A working solution was declined, so...

If I understand correctly, it is not the crossdev package being present on
the system, but the generated toolchains that cause the trouble.

I think there are less intrusive options than hardmask, such as pkg_pretend()
check or blocking offending packages from cross-${CTARGET} category.


Best regards,
Chí-Thanh Christopher Nguyễn

Ryan Hill

unread,
Jun 15, 2014, 10:30:01 PM6/15/14
to
On Sun, 15 Jun 2014 20:35:53 +0000
hasufell <hasu...@gentoo.org> wrote:

> Steven J. Long:
> >
> > "I'll see you when you get there, if you ever get there.."
> >
>
> No improvements so far. I am going to hardmask sys-devel/crossdev,
> unless someone can explain why we are still in broken stage.

Do that and we'll have to take you out behind the woodshed.


--
Ryan Hill psn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
signature.asc

hasufell

unread,
Jun 16, 2014, 9:30:01 AM6/16/14
to
Ryan Hill:
> On Sun, 15 Jun 2014 20:35:53 +0000
> hasufell <hasu...@gentoo.org> wrote:
>
>> Steven J. Long:
>>>
>>> "I'll see you when you get there, if you ever get there.."
>>>
>>
>> No improvements so far. I am going to hardmask sys-devel/crossdev,
>> unless someone can explain why we are still in broken stage.
>
> Do that and we'll have to take you out behind the woodshed.
>
>

If you think having broken packages for months in stable arch is ok,
then you are wrong.

And btw., your funny threats don't impress me anymore.

I'll bring this up to the council agenda if you like. This is a
non-trivial tree-wide problem and if toolchain keeps ignoring it, then I
will hardmask the thing.

hasufell

unread,
Jun 16, 2014, 9:40:03 AM6/16/14
to
Chí-Thanh Christopher Nguyễn:
There was a proposed solution which works perfectly fine: don't clutter
PATH with crossdev links.

If any embedded developer needs these tools in PATH he can add them
temporarily (I'm pretty sure he knows how; an elog can be added as
well), via wrapper scripts or whatnot. That's a reasonable trade-off.

However, toolchain does not agree and I don't randomly touch other
peoples packages (unless there is no response).

So there are only two things left:
* block crossdev within multilib eclasses (that sounds really wrong to me)
* hardmask it, so we are able to communicate this problem to the user

Steev Klimaszewski

unread,
Jun 16, 2014, 2:50:02 PM6/16/14
to
I'm someone who uses crossdev (and the cross compilers) quite heavily -
can you point me to a bug that you're talking about? I'm not in the
toolchain, and while I agree that temporarily adding the cross
compiler(s) to the PATH is easy, for some of us, it's easier to allow
Gentoo to do so.

I'm not a huge fan of multilib, but at the same time, I'd like to not
see crossdev being hardmasked, just to prove your point. I don't have
near as much free time as I'd like, but I may try to squeeze some time
in to help out.

hasufell

unread,
Jun 16, 2014, 3:40:03 PM6/16/14
to
Steev Klimaszewski:
>
> I'm someone who uses crossdev (and the cross compilers) quite heavily -
> can you point me to a bug that you're talking about? I'm not in the
> toolchain, and while I agree that temporarily adding the cross
> compiler(s) to the PATH is easy, for some of us, it's easier to allow
> Gentoo to do so.
>
> I'm not a huge fan of multilib, but at the same time, I'd like to not
> see crossdev being hardmasked, just to prove your point. I don't have
> near as much free time as I'd like, but I may try to squeeze some time
> in to help out.
>
>

see https://bugs.gentoo.org/show_bug.cgi?id=500338

emerge a native x86 toolchain and enable ABI_X86="32" globally. A lot of
packages randomly fail, either because of wrong PKG_CONFIG being picked
up or even wrong CC/CXX, causing failure at linking stage and whatnot.

Also check the history of this thread for a few proposed solutions.

hasufell

unread,
Jun 16, 2014, 3:50:01 PM6/16/14
to
Jeroen Roovers:
> On Mon, 16 Jun 2014 19:31:58 +0000
> hasufell <hasu...@gentoo.org> wrote:
>
>> Also check the history of this thread for a few proposed solutions.
>
> The history of this thread and the history of gx86-multilib and
> crossdev development suggest that crossdev was doing nothing wrong until
> gx86-multilib came around and a problem was found between them. Masking
> either for the benefit of the other would be, and let me quote the
> history of this thread out of context just to fit in with the tone and
> mode this sub-thread has taken, "asinine".
>

This isn't about right or wrong. This is about actual breakage on stable
systems.

Solutions were proposed, nothing has happened for months.

So I don't see what else we can do here other than taking more radical
steps to INFORM users of these possible breakages... and that's exactly
what a hardmask is for.

Jeroen Roovers

unread,
Jun 16, 2014, 3:50:03 PM6/16/14
to
On Mon, 16 Jun 2014 19:31:58 +0000
hasufell <hasu...@gentoo.org> wrote:

> Also check the history of this thread for a few proposed solutions.

The history of this thread and the history of gx86-multilib and
crossdev development suggest that crossdev was doing nothing wrong until
gx86-multilib came around and a problem was found between them. Masking
either for the benefit of the other would be, and let me quote the
history of this thread out of context just to fit in with the tone and
mode this sub-thread has taken, "asinine".


jer

Joshua Kinard

unread,
Jun 16, 2014, 4:10:01 PM6/16/14
to
What about those of us who have been using crossdev to generate
cross-compilers for years w/o issue, because we run non-multilib?
Hardmasking crossdev to solve multilib problems doesn't accomplish anything,
other than just irk us. Why not hardmask the multilib stuff instead and
leave crossdev alone?

Neither hardmask solution is viable, since you'll inconvenience one side for
the sake of the other. That's not how you solve problems.

Is my understanding of the issue correct, in that, per Bug #500338, crossdev
was used to merge an i686-pc-linux-gnu cross-toolchain onto an
x86_64-pc-linux-gnu system, resulting in /usr/bin/cross-pkg-config being
linked to /usr/bin/i686-pc-linux-gnu-pkg-config, which causes the problem
reported in that bug?

If so, is it sensible to allow crossdev to install a cross-toolchain when
the underlying machine architecture is the same, just a different ABI?
I.e., would a solution be to prevent i686-on-x86_64 or mips64-on-mips, but
still allow mips64-on-x86_64, and such?

--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

hasufell

unread,
Jun 16, 2014, 4:30:01 PM6/16/14