1 |
On Tue, Jun 17, 2014 at 10:56 -0400, Alexandre Rostovtsev wrote: |
2 |
> All multilib packages that use pkgconfig, for one thing. (Which means almost |
3 |
> all multilib packages.) Because current crossdev versions blindly install their |
4 |
> /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting the binary |
5 |
> belonging to pkgconfig[abi_x86_32]. |
6 |
|
7 |
Well I've spent far too long at crossdev code, only to see this and realise |
8 |
you can simply hard-mask: |
9 |
cross-i686-pc-linux-gnu/{binutils,gcc,glibc,pkg-config} |
10 |
in the amd64 multilib profile, unless I'm missing something. You'd be |
11 |
hard-pushed to install a clashing crossdev with such a mask, afaict. |
12 |
|
13 |
If you do want to change crossdev[1], afaict you're looking at interaction |
14 |
between toolchain.eclass (and toolchain-binutils, and likely -funcs), |
15 |
crossdev and gcc-config. I could well be wrong, as ever. This is just my |
16 |
preliminary understanding, and maybe it'll provoke a more thorough |
17 |
explanation. |
18 |
|
19 |
Crossdev set_links() links the overlay to the tree. toolchain.eclass installs |
20 |
the versioned links so the internal gcc-bin path is exposed in /usr/bin, in |
21 |
toolchain_src_install(). For cross-toolchains, it only installs prefixed ones: |
22 |
dosym ${BINPATH}/${CTARGET}-${x} /usr/bin/${CTARGET}-${x}-${GCC_CONFIG_VER} |
23 |
|
24 |
For a native compiler it first, in: "${D}"${BINPATH} does: |
25 |
ln -sf ${CTARGET}-${x} ${x} # unversioned private link |
26 |
dosym ${BINPATH}/${CTARGET}-${x} /usr/bin/${x}-${GCC_CONFIG_VER} |
27 |
|
28 |
..then the above. Note that the prefixed link is effectively a race as to |
29 |
which was installed last, but only in the case of a clash. |
30 |
|
31 |
gcc-config update_wrappers() makes links in the user's path, though all of |
32 |
them are run via wrapper.c[2], aka /usr/lib/misc/gcc-config. This is a |
33 |
multi-switch binary based on argv[0]/$0. However it specifically notes |
34 |
that it's intended to be used with a PATH-based setup [3]: |
35 |
|
36 |
/* Find the first file with suitable name in PATH. The idea here is |
37 |
* that we do not want to bind ourselfs to something static like the |
38 |
* default profile, or some odd environment variable, but want to be |
39 |
* able to build something with a non default gcc by just tweaking |
40 |
* the PATH ... */ |
41 |
|
42 |
crossdev dirs are added to path after system ones in env.d; that's where |
43 |
gcc-config gets the paths to use from. |
44 |
|
45 |
crossdev uninstall() removes CTARGET-based links. Note that your native |
46 |
machine CBUILD == CHOST, also has CTARGET = CHOST, so this would also |
47 |
be a reason to block/mask according to arch. |
48 |
|
49 |
I haven't reviewed wrapper.c as well as I'd like: some of it seems a bit |
50 |
odd but I'd need more time. I did wonder why it doesn't just use |
51 |
readlink(3P) til I saw that comment. |
52 |
|
53 |
Anyhow, that all seems a bit pointless when you can just hardmask the |
54 |
specific crossdev configuration that causes the problem on multilib |
55 |
profiles, and the same mechanism can be applied elsewhere, as decided |
56 |
by the arch-team (eg for: o32/n32/n64) |
57 |
|
58 |
Although canadian-cross and ROOT-based toolchains are another matter. |
59 |
|
60 |
Regards, |
61 |
steveL |
62 |
|
63 |
[1] ie stop installing symlinks in /usr/bin for CTARGET-gcc, as well as |
64 |
env.d files, and just provide a sh wrapper in each PORTAGE_CONFIGROOT |
65 |
(= cross-overlay) that can be sourced from /etc/profile or anywhere |
66 |
else, to add the same settings instead as and when the user chooses. |
67 |
|
68 |
The most you'd need is the ability to choose whether it takes precedence |
69 |
over current PATH or not, and that's probably easiest with a variant |
70 |
'source' ('.' in shell) so cross-builds do, and the profile one doesn't. |
71 |
|
72 |
[2] http://git.overlays.gentoo.org/gitweb/?p=proj/gcc-config.git;a=blob;f=wrapper.c;hb=HEAD |
73 |
[3] ll 125-129 h=b00e8187a6063e329049ab9a57023fe9113c598d;hb=HEAD |
74 |
-- |
75 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |