I think RAP simply pulls in attr, and we need to see if we can fix it. Can you file a bug for it on bugs.gentoo.org if you haven't yet?
Thanks, Fabian On 15-12-2020 21:44:01 -0500, Joey Dumont wrote: > At this exploratory stage, I do not need a libc in my prefix. Arch is a > rolling > release, so I currently glibc-2.32, which I believe is the latest. > > Good to hear that it's working on both Ubuntu and CentOS: those are the likely > platforms for any production work. I was mostly curious to see how it would > fare > on my home system. It's a nice way of getting acquainted with portage as > well. > > The PREFIX_DISABLE_RAP=yes bootstrap worked! This is enough for me on Arch > Linux, although I'd be curious to know why RAP fails. I just tried emerging > attr > on my non-RAP prefix, and it also fails. Do you know if it's a function of the > host glibc? > > In any case, I think this is fine. I'll set prefix up on a CentOS or Ubuntu > system with a prefixed libc. > > Thanks! > > Joey Dumont (Profile[1]) > The supreme elegance of Nature lies in its apparent simplicity. > > > On Tue, 15 Dec 2020 at 02:55, Fabian Groffen <[email protected][2]> wrote: > > I know this is not a small ask, but do you need a libc in your Prefix? > > E.g. do you anticipate one is neccesary because Arch's is too old? > > > > If not, could you try bootstrapping again from scratch with > > PREFIX_DISABLE_RAP=yes in your environment set. > > > > I see that yesterday's Ubuntu bootstrap (using RAP) succeeded, and the > > CentOS bootstrap succeeded not too long ago, so this may be a total > > pointless ask. > > > > Thanks, > > Fabian > > > > > > On 14-12-2020 20:59:52 -0500, Joey Dumont wrote: > > > I tried contacting the mailing list a couple times, but it seems my > > > messages weren't going through. Trying with plain text email, sorry if > > > I generated noise. > > > > > > I've been trying to bootstrap Gentoo Prefix on Arch Linux. However, I > > > am having issues during stage3. Specifically, I am having trouble > > > building sys-apps/attr-2.4.48-r4. Actually, it builds fine, but then > > > the symbol version sanity check fails: > > > > > > * ERROR: sys-apps/attr-2.4.48-r4::gentoo failed (install phase): > > > * symbol version sanity check failed; please comment on > > > https://bugs.gentoo.org/644048[3] > > > * > > > * Call stack: > > > * ebuild.sh, line 125: Called src_install > > > * environment, line 2163: Called multilib-minimal_src_install > > > * environment, line 1501: Called multilib_foreach_abi > > > 'multilib-minimal_abi_src_install' > > > * environment, line 1734: Called multibuild_foreach_variant > > > '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' > > > * environment, line 1388: Called _multibuild_run > > > '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' > > > * environment, line 1386: Called _multilib_multibuild_wrapper > > > 'multilib-minimal_abi_src_install' > > > * environment, line 474: Called multilib-minimal_abi_src_install > > > * environment, line 1491: Called multilib_src_install > > > * environment, line 1965: Called die > > > * The specific snippet of code: > > > * die "symbol version sanity check failed; please > > > comment on https://bugs.gentoo.org/644048[4]"; > > > > > > I've checked the symbols, and it does seem that the issue fits the > > > parameters of bug 644048: > > > > > > ~/software/gentoo/2020.12/tmp/bin/x86_64-pc-linux-gnu-readelf -sW > > > /home/valandil/software/gentoo/2020.12/var/tmp/portage/sys-apps/attr-2.4.48- > > r4/image/home/valandil/software/gentoo/2020.12/usr/lib64/libattr.so.1 > > > | grep getxattr > > > 13: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > > > lgetxattr@GLIBC_2.3 (7) > > > 26: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > > > fgetxattr@GLIBC_2.3 (7) > > > 31: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > > > getxattr@GLIBC_2.3 (7) > > > 43: 00000000000040e0 0 FUNC GLOBAL DEFAULT 13 > > >fgetxattr@ATTR_1.0 > > > 54: 00000000000040a0 0 FUNC GLOBAL DEFAULT 13 > > >getxattr@ATTR_1.0 > > > 62: 00000000000040c0 0 FUNC GLOBAL DEFAULT 13 > > >lgetxattr@ATTR_1.0 > > > 47: 00000000000040c0 24 FUNC LOCAL DEFAULT 13 > > >libattr_lgetxattr > > > 50: 00000000000040a0 24 FUNC LOCAL DEFAULT 13 > > >libattr_getxattr > > > 57: 00000000000040e0 23 FUNC LOCAL DEFAULT 13 > > >libattr_fgetxattr > > > 83: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > > lgetxattr@@GLIBC_2.3 > > > 89: 00000000000040a0 0 FUNC GLOBAL DEFAULT 13 > > >getxattr@ATTR_1.0 > > > 97: 00000000000040c0 0 FUNC GLOBAL DEFAULT 13 > > >lgetxattr@ATTR_1.0 > > > 113: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > > fgetxattr@@GLIBC_2.3 > > > 123: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > > >getxattr@@GLIBC_2.3 > > > 127: 00000000000040e0 0 FUNC GLOBAL DEFAULT 13 > > >fgetxattr@ATTR_1.0 > > > > > > I tried adding the ebuild/patch attached to the bug above by adding a > > > local repo, and masking earlier versions of sys-apps/attr in > > > tmp/etc/portage/package.mask, but since the patch modifies a file > > > alled Makemodules.am, portage triggers automake-1.15, which is not > > > available on the prefix at this point. I tried installing it by adding > > > sys-devel/automake to the list of pkgs installed at this point, but > > > this fails at the install_qa_check_prefix stage, as automake contains > > > non-prefixed shebangs. > > > > > > What's the way forward here? Should I write my own automake patch to > > > fix the non-prefixed shebang? Or is that a known issue in Prefix with > > > a better (known) solution? > > > > > > Thanks for any help! > > > > > > Joey Dumont (Profile) > > > The supreme elegance of Nature lies in its apparent simplicity. > > > > > > > -- > > Fabian Groffen > > Gentoo on a different level > > > References > 1. http://blog.joey-dumont.ca/ > 2. mailto:[email protected] > 3. https://bugs.gentoo.org/644048 > 4. https://bugs.gentoo.org/644048 -- Fabian Groffen Gentoo on a different level
signature.asc
Description: PGP signature
