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

[Francois Bissey]

Hi,



> On 8/11/2017, at 14:47, Benda Xu <heroxbd@g.o> wrote:
>
> 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.
>




You are not the first one to try to recruit me :)

I guess I don’t like the interview questions.

I don’t know how long I will have the hardware for. I cannot imagine

having it past June 2018. We probably should look for someone with

power8+ hardware.



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


Well baselayout-prefix is installed at the beginning of stage 2. It is part of

the packages installed by stage 2. I think we should make an exception for it

to be plain baselayout on rap in stage 2 as well as it is in stage 3.



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


Funny thing, I tried to use it to my advantage by defining DYNAMIC_LINKER_PREFIX.

And it seemed to do the right thing and was in all the right place that I could think of

in the dump spec but the binaries produced where all lacking the prefix in front

of /lib64/ld64.so. 

Which is why I ended doing that particular sed. There must be something more

to do if you want to use DYNAMIC_LINKER_PREFIX.



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


I’ll look in the configure script. That seem curious it could ppc only but there

may be a motivation for power8 and over.



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


It is not quoted. If your group name has a space in it, `cp` think the second

part of your group should be a new argument. Can have interesting side effects

depending on the part in question.

Here is what happens:

gmake[1]: Entering directory '/dev/shm/portage/sys-apps/attr-2.4.47-r2/work/attr-2.4.47-abi_ppc_64.ppc64/attr'

../include/install-sh -o frb15 -g domain users -m 755 -d /shared/work_no_backup/ppc64-prefix/bin

cp: cannot stat 'users': No such file or directory



Cheers,

François