Re: [gentoo-alt] Prefix hijacking

[Steven Trogdon]

Thanks Benda. At least there is a rational reason for what seemed to be a
"hijacking". In my original post I noted that

eselect profile list

returned

!!! Warning: Failed to determine ${ARCH}. Please submit a bug report.
!!! Error: Cannot determine architecture
!!! Error: Failed to get a list of valid profiles

I was able to make changes to
$EPREFIX/usr/share/eselect/libs/package-manager.bash
so that I could see the standalone profile which now looks a lot better than the
prefix-rpath profile. So now to emerging @system. With the new profile where
will libs be installed - under $EPREFIX/usr/lib or $EPREFIX/usr/lib64? This
presents a problem in installing coreutils with USE=acl. The sys-apps/acl libs
get installed under $EPREFIX/usr/lib64 but apparently coreutils looks for them
under $EPREFIX/usr/lib. And of courses libs were installed under
$EPREFIX/usr/lib on my old rpath-prefix with glibc. My old linker may be at
issue!

Steven

---
On Thu, 18 Feb 2016 13:22:57 +0900
Benda Xu <heroxbd@g.o> wrote:

> Hi Steven,
>
> I am really sorry for the confusion in glibc on Prefix.  We are on the
> way to make it work out-of-the-box, finally.
>
> Steven Trogdon <strogdon@×××××.edu> writes:
>
> > OK, I think I have found part of my problem. Here is a partial result
> > from updating world
> >
> > [ebuild   R    ] dev-libs/libltdl-2.4.6  ABI_X86="(-64*)"
> > [ebuild   R    ] virtual/service-manager-0  KERNEL="(-linux*)"
> > [ebuild   R    ] dev-libs/mpfr-3.1.3_p4  ABI_X86="(-64*)"
> > [ebuild   R    ] dev-libs/mpc-1.0.3  ABI_X86="(-64*)"
> > [ebuild  N    #] dev-libs/libiconv-1.14-r1  USE="static-libs"
> > [ebuild   R    ] virtual/libiconv-0-r2  ABI_X86="(-64*)" ELIBC="(-glibc*)"
> > [ebuild  N    #] dev-libs/libintl-0.19.7  USE="threads -static-libs"
> > [uninstall     ] sys-libs/glibc-2.19-r1
> > [blocks b      ] sys-libs/glibc ("sys-libs/glibc" is blocking
> > dev-libs/libiconv-1.14-r1)
> > [blocks b      ] sys-libs/glibc ("sys-libs/glibc" is blocking
> > dev-libs/libintl-0.19.7)
> > [ebuild   R    ] virtual/libintl-0-r2  ABI_X86="(-64*)" ELIBC="(-glibc*)"
> > [ebuild   R    ] sys-libs/zlib-1.2.8-r1  ABI_X86="(-64*)"
> > [ebuild   R    ] dev-libs/expat-2.1.0-r4  ABI_X86="(-64*)"
> > [ebuild   R    ] dev-libs/iniparser-3.1-r1  ABI_X86="(-64*)"
> >
> > I don't know about the ABI changes, but notice that portage wants to
> > remove sys-libs/glibc. This will break my prefix since I'm not using
> > the host glibc but a prefix installed one. Of course things are pretty
> > much broken now since I can't perform a meaningful update. Some
> > ebuilds have the 'elibc_glibc' useflag to prevent installing things
> > that conflict with an installed glibc - gettext is an example. That
> > flag just doesn't work. I'm unable to install gettext (which is
> > already installed) because of a file collision with a header provided
> > by glibc. I have tried everything I can think of to enable the
> > 'elibc_glibc' flag without success. I can certainly fix the ebuild to
> > make it work but there remains the issue with glibc and the need for
> > libiconv and libintl which are not needed but portage insists on
> > installing? This has not been a problem until recently.
>
> What profile are you using?  From your previous email it seems wrong:
>
> > Any ideas as to why I now have no valid ARCH set? The
> > etc/portage/make.profile symlink is in place
>
> > ls -al ~/etc/portage/make.profile
> > lrwxrwxrwx 1 strogdon math 71 Dec 24 00:17
> > /storage/strogdon/gentoo-prefix/etc/portage/make.profile ->
> > /storage/strogdon/gentoo-prefix/usr/portage/profiles/prefix/linux/amd64
>
> > Any pointers as to where to look?
>
> prefix/linux/amd64 is for prefix-rpath, which replies on host libc.
> What should be used is prefix/linux-standalone/amd64, see bug 521138[1].
>
> On my system,
>
> $ eselect profile list
> Available profile symlink targets:
>   [1]   gentoo_prefix:prefix/linux/amd64
>   [2]   gentoo_prefix:prefix/linux-standalone/amd64 *
>
> Therefore
>
> $ eselect profile set 2
>
> would do the profile switch.
>
> > Now it's possible that my prefix is messed up but until recently my
> > non-host glibc has been coexisting nicely with prefix.
>
> There is still hope to fix the running system.  After switching to the
> currect profile, emerge @system again.  I am not sure if the glibc in
> prefix overlay would work[2].  If not, give the one in my overlay[3] a
> try.
>
> I am available to help with any further problems.
>
> Yours,
> Benda
>
> 1. https://bugs.gentoo.org/show_bug.cgi?id=521138
> 2. https://bugs.gentoo.org/show_bug.cgi?id=473728
> 3. https://gitweb.gentoo.org/dev/heroxbd.git/tree/sys-libs/glibc
>