[gentoo-alt] rap prefix on ppc64 reloaded

[François Bissey]

Hi,

So last month I lost my original rap prefix install.
A documentation error from IBM means that I pulled the wrong disk :(

Re-installing the prefix proved a challenge. Quite a few
things worked out of the box thanks to my last report at
the beginning of the year but I got a few new issues.

1) baselayout-prefix still doesn't have a suitable ppc64
keyword. This hits fairly early on in stage 2 I think.
Vague memories from my previous experience suggested that it
wasn't necessary. So I snipped it from the list in bootstrap-rap.sh.
Which seemed to be fine until much later, after solving other
issues it came back to bite in stage 3 (after I fixed point 3).
stage 3 tried to emerge baselayout and it failed. Both variant
of baselayout prepare the system for multilib. If installed early
enough it will move files around and link {,usr/}lib to {,usr/}lib64
and so on. But it will fail miserably if there is stuff it doesn't
know about in {,usr/}lib. Which, at the stage 3 level, is pretty much 
the case. I manually fixed things and baselayout merged successfully.
Should rap use baselayout directly in stage 2? That would solve the 
keyword problem and match what happens in stage 3.


2) gcc 6.4.0 and 5.4.0 failed to bootstrap. Two issues:
a) I needed to export LIBRARY_PATH=${EPREFIX}/usr/lib64
(I wonder if it was related to baselayout but I haven't checked)
b) the formula to insert the prefix to the location ld64.so
was defeated again by new peculiarity in the
gcc/config/rs6000/linux64.h code.
I ended up adding the following formula in my own
${EPREFIX}/etc/portage/profile/profile.bashrc

if [[ ${CATEGORY}/${PN} == sys-devel/gcc && ${EBUILD_PHASE} == configure 
]]; then
     cd "${S}"
     sed -i 
"s:%(dynamic_linker_prefix)/lib64/ld64:${EPREFIX}/lib64/ld64:g" \
         gcc/config/rs6000/linux64.h

fi

3) glibc issues. This is detailed in
https://archives.gentoo.org/gentoo-alt/message/1efbc07a12332306715cfaebf38c8897

The additional issue is that I need also this on ppc:
https://patchwork.ozlabs.org/patch/686205/

4) acl/attr not really a prefix issue but I guess it is most likely
to show up in that kind of environment. I am sure I complained about
other packages doing the same thing before. Those two are a pair because
they share the build system. Both identify the primary group with
id -g -n
which gives you the name of the group instead of the numeric ID.
Problem is my group on that system, which is loosely linked to AD is
domain users
This value is passed to the install command which in turn passes it to
the "cp" command which doesn't know what to do with "users".
The cure is to use the numeric group ID, either by patching configure
(not true autoconf as far as I can tell) to use "id -g" or setting a 
variable (INSTALL_GROUP I think it was) to that value.

But at last, today I handed the system back for use to end users.
Validation will take a bit of time as the only user left is currently
on the other side of the world :)

Francois