Gentoo Archives: gentoo-alt

From: Benda Xu <heroxbd@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] rap prefix on ppc64 reloaded
Date: Wed, 08 Nov 2017 01:47:39
In Reply to: [gentoo-alt] rap prefix on ppc64 reloaded by "François Bissey"
Hi François,

Thank you for this detailed report of ppc64 Prefix.  The profile of
ppc64 is not there because we know we donot have support for it.  Your
diagnosis is crucial for us to get ready for it.  However, I dont have
access to ppc64, therefore I will only comment on general issues.

Are you interested in joining our Gentoo Prefix team to support ppc64?
Your past contributions to Gentoo Science and Prefix are well recognized
and received.  If you would like step up I will be happy to support you
through the process.

> 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 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.
baselayout-prefix is for prefix-rpath. For prefix-standalone aka. RAP, baselayout is used. Our profiles are no-multilib, which in Gentoo means lib is a symlink to lib64. stage 3 baselayout fails if lib already exists and the creation of symlink fails. This happens if some package, like gentoo-functions, installs into EPREFIX/lib. The solution is install baselayout in stage3 as early as possible, before gentoo-functions.
> 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)
This does not look good. The logic should have been covered by export LDFLAGS="-L${ROOT}/usr/$(get_libdir)" in stage3,
> b) the formula to insert the prefix to the location 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
Yes, this should be fixed. We'd better reuse the DYNAMIC_LINKER_PREFIX logic inside rs6000. It was introduced for IBM advanced toolchain. I am not sure. Probably glibc has a different set of kernel version requirements on ppc64.
> The additional issue is that I need also this on ppc: >
> 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.
Sorry I don't fully understand why cp fails if supplied with a group name. Yours, Benda


Subject Author
Re: [gentoo-alt] rap prefix on ppc64 reloaded Francois Bissey <francois.bissey@×××××××××××××.nz>