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

[R0b0t1]

Hello,

On Tue, Nov 7, 2017 at 10:57 PM, Francois Bissey
<francois.bissey@×××××××××××××.nz> wrote:
> 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
>

Thank you for your troubleshooting, I have been trying to set up a RAP
installation on GCC's POWER8 machine for some time now.

Cheers,
     R0b0t1