Gentoo Archives: gentoo-alt

From: gmt@×××××.us
To: gentoo-alt@l.g.o
Subject: [gentoo-alt] multilib vs. prefix
Date: Fri, 14 Jun 2013 20:42:57
Message-Id: 00fa01ce693f$7445a320$5cd0e960$
I seem to recall that, at some point not too long ago, prefix was multilib
compatible, before the current masking occurred.


In my ongoing experimentation with crossdev under prefix, thus far I am not
able to build multilib cross-gcc's from the no-multilib profile.  I don't
know, right now, if the same problem applies to non-prefixed gentoo installs
(if someone wanted to test that out for me I'd be much obliged).  In prefix
what I'm seeing is that attempts to build the stage2 (crossdev stage 2) gcc
fail building the non-default-abi gcclib.  It's a link failure that occurs
due to the lack of any non-default-abi-libdir on the library paths generated
in the build/gcclib/32 Makefile.


Anyhow, I'm wondering, is there somebody out there who knows what is behind
the decision to mask multilib in prefix-portage (or made it themselves), and
what it would take to fix it?  By any chance, does the limitation pertain to
mostly to gcc-config and the special prefix magic that happens in the
dynamically generated gcc wrappers?


Because, going forward, it seems like that's a problem we need to fix,
anyhow, due to the no-multilib profile deprecation.  I don't know if that
also explains the inability to build the multilib cross-gcc's, or not, but
it does seem that, going forward, a no-multilib requirement is not an
albatross we want around prefix-portage's neck.


Now that bleeding-edge GNU toolchains are starting to support sysroot and
relocatable toolchains, perhaps we could start disentangling or
conditionalizing prefix-portage's reliance on the gcc-wrappers, and this
would begin to relieve whatever forces are pushing us into this no-multilib
corner?  Or am I barking up the wrong tree with that?


Eager to hear your thoughts,




Subject Author
Re: [gentoo-alt] multilib vs. prefix Fabian Groffen <grobian@g.o>