1 |
Hi, |
2 |
|
3 |
So last month I lost my original rap prefix install. |
4 |
A documentation error from IBM means that I pulled the wrong disk :( |
5 |
|
6 |
Re-installing the prefix proved a challenge. Quite a few |
7 |
things worked out of the box thanks to my last report at |
8 |
the beginning of the year but I got a few new issues. |
9 |
|
10 |
1) baselayout-prefix still doesn't have a suitable ppc64 |
11 |
keyword. This hits fairly early on in stage 2 I think. |
12 |
Vague memories from my previous experience suggested that it |
13 |
wasn't necessary. So I snipped it from the list in bootstrap-rap.sh. |
14 |
Which seemed to be fine until much later, after solving other |
15 |
issues it came back to bite in stage 3 (after I fixed point 3). |
16 |
stage 3 tried to emerge baselayout and it failed. Both variant |
17 |
of baselayout prepare the system for multilib. If installed early |
18 |
enough it will move files around and link {,usr/}lib to {,usr/}lib64 |
19 |
and so on. But it will fail miserably if there is stuff it doesn't |
20 |
know about in {,usr/}lib. Which, at the stage 3 level, is pretty much |
21 |
the case. I manually fixed things and baselayout merged successfully. |
22 |
Should rap use baselayout directly in stage 2? That would solve the |
23 |
keyword problem and match what happens in stage 3. |
24 |
|
25 |
|
26 |
2) gcc 6.4.0 and 5.4.0 failed to bootstrap. Two issues: |
27 |
a) I needed to export LIBRARY_PATH=${EPREFIX}/usr/lib64 |
28 |
(I wonder if it was related to baselayout but I haven't checked) |
29 |
b) the formula to insert the prefix to the location ld64.so |
30 |
was defeated again by new peculiarity in the |
31 |
gcc/config/rs6000/linux64.h code. |
32 |
I ended up adding the following formula in my own |
33 |
${EPREFIX}/etc/portage/profile/profile.bashrc |
34 |
|
35 |
if [[ ${CATEGORY}/${PN} == sys-devel/gcc && ${EBUILD_PHASE} == configure |
36 |
]]; then |
37 |
cd "${S}" |
38 |
sed -i |
39 |
"s:%(dynamic_linker_prefix)/lib64/ld64:${EPREFIX}/lib64/ld64:g" \ |
40 |
gcc/config/rs6000/linux64.h |
41 |
|
42 |
fi |
43 |
|
44 |
3) glibc issues. This is detailed in |
45 |
https://archives.gentoo.org/gentoo-alt/message/1efbc07a12332306715cfaebf38c8897 |
46 |
|
47 |
The additional issue is that I need also this on ppc: |
48 |
https://patchwork.ozlabs.org/patch/686205/ |
49 |
|
50 |
4) acl/attr not really a prefix issue but I guess it is most likely |
51 |
to show up in that kind of environment. I am sure I complained about |
52 |
other packages doing the same thing before. Those two are a pair because |
53 |
they share the build system. Both identify the primary group with |
54 |
id -g -n |
55 |
which gives you the name of the group instead of the numeric ID. |
56 |
Problem is my group on that system, which is loosely linked to AD is |
57 |
domain users |
58 |
This value is passed to the install command which in turn passes it to |
59 |
the "cp" command which doesn't know what to do with "users". |
60 |
The cure is to use the numeric group ID, either by patching configure |
61 |
(not true autoconf as far as I can tell) to use "id -g" or setting a |
62 |
variable (INSTALL_GROUP I think it was) to that value. |
63 |
|
64 |
But at last, today I handed the system back for use to end users. |
65 |
Validation will take a bit of time as the only user left is currently |
66 |
on the other side of the world :) |
67 |
|
68 |
Francois |