Re: [gentoo-alt] rap prefix on ppc64 reloaded

[Benda Xu]

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 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.


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.



  https://gitweb.gentoo.org/repo/proj/prefix.git/tree/scripts/bootstrap-prefix.sh#n1614





> 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,



  https://gitweb.gentoo.org/repo/proj/prefix.git/tree/scripts/bootstrap-prefix.sh#n1568



> 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


Yes, this should be fixed.  We'd better reuse the DYNAMIC_LINKER_PREFIX

logic inside rs6000.  It was introduced for IBM advanced toolchain.



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


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:
> 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.


Sorry I don't fully understand why cp fails if supplied with a group

name.



Yours,

Benda