Hi,
> On 8/11/2017, at 14:47, Benda Xu <[email protected]> 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
