[gentoo-dev] Re: Re: Re: Re: crossdev and multilib interference

["Steven J. Long" <slong@rathaus.eclipse.co.uk>]

On Tue, Jun 17, 2014 at 10:56 -0400, Alexandre Rostovtsev wrote:
> All multilib packages that use pkgconfig, for one thing. (Which means almost
> all multilib packages.) Because current crossdev versions blindly install their
> /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting the binary
> belonging to pkgconfig[abi_x86_32].

Well I've spent far too long at crossdev code, only to see this and realise
you can simply hard-mask:
  cross-i686-pc-linux-gnu/{binutils,gcc,glibc,pkg-config}
in the amd64 multilib profile, unless I'm missing something. You'd be
hard-pushed to install a clashing crossdev with such a mask, afaict.

If you do want to change crossdev[1], afaict you're looking at interaction
between toolchain.eclass (and toolchain-binutils, and likely -funcs),
crossdev and gcc-config. I could well be wrong, as ever. This is just my
preliminary understanding, and maybe it'll provoke a more thorough
explanation.

Crossdev set_links() links the overlay to the tree. toolchain.eclass installs
the versioned links so the internal gcc-bin path is exposed in /usr/bin, in
toolchain_src_install(). For cross-toolchains, it only installs prefixed ones:
 dosym ${BINPATH}/${CTARGET}-${x} /usr/bin/${CTARGET}-${x}-${GCC_CONFIG_VER}

For a native compiler it first, in: "${D}"${BINPATH} does:
 ln -sf ${CTARGET}-${x} ${x}     # unversioned private link
 dosym ${BINPATH}/${CTARGET}-${x} /usr/bin/${x}-${GCC_CONFIG_VER}
 
..then the above. Note that the prefixed link is effectively a race as to
which was installed last, but only in the case of a clash.

gcc-config update_wrappers() makes links in the user's path, though all of
them are run via wrapper.c[2], aka /usr/lib/misc/gcc-config. This is a
multi-switch binary based on argv[0]/$0. However it specifically notes
that it's intended to be used with a PATH-based setup [3]:

/* Find the first file with suitable name in PATH.  The idea here is
 * that we do not want to bind ourselfs to something static like the
 * default profile, or some odd environment variable, but want to be
 * able to build something with a non default gcc by just tweaking
 * the PATH ... */

crossdev dirs are added to path after system ones in env.d; that's where
gcc-config gets the paths to use from.

crossdev uninstall() removes CTARGET-based links. Note that your native
machine CBUILD == CHOST, also has CTARGET = CHOST, so this would also
be a reason to block/mask according to arch.

I haven't reviewed wrapper.c as well as I'd like: some of it seems a bit
odd but I'd need more time. I did wonder why it doesn't just use
readlink(3P) til I saw that comment.

Anyhow, that all seems a bit pointless when you can just hardmask the
specific crossdev configuration that causes the problem on multilib
profiles, and the same mechanism can be applied elsewhere, as decided
by the arch-team (eg for: o32/n32/n64)

Although canadian-cross and ROOT-based toolchains are another matter.

Regards,
steveL

[1] ie stop installing symlinks in /usr/bin for CTARGET-gcc, as well as
env.d files, and just provide a sh wrapper in each PORTAGE_CONFIGROOT
(= cross-overlay) that can be sourced from /etc/profile or anywhere
else, to add the same settings instead as and when the user chooses.

The most you'd need is the ability to choose whether it takes precedence
over current PATH or not, and that's probably easiest with a variant
'source' ('.' in shell) so cross-builds do, and the profile one doesn't.

[2] http://git.overlays.gentoo.org/gitweb/?p=proj/gcc-config.git;a=blob;f=wrapper.c;hb=HEAD
[3] ll 125-129 h=b00e8187a6063e329049ab9a57023fe9113c598d;hb=HEAD
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)