Created attachment 678541 [details] Output of ${EPREFIX}/tmp/bin/emerge --info As discussed on the gentoo-alt mailing list, I have been trying to bootstrap Gentoo Prefix on Arch Linux. However, boostrapping fails when trying to emerge sys-apps/attr-2.4.48-r4. It fails the version version sanity check, and mentions bug 644048. Here is the error output: > make[3]: Leaving directory '/home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/work/attr-2.4.48-abi_x86_64.amd64' > libtool: warning: 'libattr.la' has not been installed in '/home/valandil/software/gentoo/usr/lib64' > libtool: install: /usr/bin/install -c .libs/attr /home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/image/home/valandil/software/gentoo/bin/attr > libtool: warning: 'libattr.la' has not been installed in '/home/valandil/software/gentoo/usr/lib64' > libtool: install: /usr/bin/install -c .libs/getfattr /home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/image/home/valandil/software/gentoo/bin/getfattr > libtool: warning: 'libattr.la' has not been installed in '/home/valandil/software/gentoo/usr/lib64' > libtool: install: /usr/bin/install -c .libs/setfattr /home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/image/home/valandil/software/gentoo/bin/setfattr > make[2]: Leaving directory '/home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/work/attr-2.4.48-abi_x86_64.amd64' > make[1]: Leaving directory '/home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/work/attr-2.4.48-abi_x86_64.amd64' > x86_64-pc-linux-gnu-readelf: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory > x86_64-pc-linux-gnu-readelf: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory > # readelf -V /home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/image/home/valandil/software/gentoo/usr/lib64/libattr.so.1 > # readelf -sW /home/valandil/software/gentoo/var/tmp/portage/sys-apps/attr-2.4.48-r4/image/home/valandil/software/gentoo/usr/lib64/libattr.so.1 > * 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 > * > * 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"; I looked at bug 644048, comment 39 and added the ebuild/patch to a local repo in the prefix. However, because the patch modifies Makemodules.am, automake-1.15 is triggered. Trying to emerge it results in an error in the install_qa_check_prefix stage: > * QA Notice: the following files use invalid (possible non-prefixed) shebangs: > * home/valandil/software/gentoo/2020.12/usr/bin/aclocal-1.16:/usr/sbin/perl (script aclocal-1.16 installed in PATH but interpreter /usr/sbin/perl not found) > * home/valandil/software/gentoo/2020.12/usr/bin/automake-1.16:/usr/sbin/perl (script automake-1.16 installed in PATH but interpreter /usr/sbin/perl not found) > * ERROR: sys-devel/automake-1.16.3-r1::gentoo failed: > * Aborting due to QA concerns: invalid shebangs found > * > * Call stack: > * misc-functions.sh, line 1293: Called install_qa_check > * misc-functions.sh, line 138: Called source 'install_symlink_html_docs' > * 05prefix, line 138: Called install_qa_check_prefix > * 05prefix, line 134: Called die > * The specific snippet of code: > * die "Aborting due to QA concerns: invalid shebangs found" Note that the bootstrap succeeds if PREFIX_DISABLE_RAP=yes is set, as attr is not emerged then. I've attached the output of emerge --info on the bug report. What would be the best way to fix this? Fix the symbol version issue without modifying Makemodules.am, or having a version of automake suitable for prefix?
In your non-RAP prefix, if you emerge attr it also fails to compile, right? In your non-RAP prefix, do you have automake/perl installed? (I believe automake and thus perl is still part of the system set, so it should.) If you use your modified ebuild there, can you run eautoreconf from the ebuild, and does that bring you further?
Created attachment 678652 [details] attr ebuild for bug 644048
Indeed, sys-apps/attr fails to compile even in the non-RAP prefix. I've tried adding the new ebuild in that prefix, but it also fails. I've attached the ebuild. It's similar to the one in bug 644048, but "rebased" to the attr-2.4.48-r4 that I had in my prefix, and with inherit autotools and eautoreconf added in src_prepare. It fails with the same error as before, but I'll attach the full logs.
Created attachment 678655 [details] Build log for attr-2.4.48
I noticed that the build log complained that it couldn't find $(tc-getREADELF), and that's why it was failing. However, even with readelf hardcoded into the ebuild, the symbol version check. I'll attach the more informative ebuild log.
Created attachment 678766 [details] Build log for attr-2.4.48 with hardcoded readelf
This is embarassing, but I introduced a typo in my attr-2.4.48-r5.ebuild. Fixing the typo makes the build succeed in my non-RAP prefix. When trying to bootstrap the RAP prefix with that attr version, it is necessary to add a dependency on automake, as we need to run eautoreconf. I'll attach the fixed ebuild. Unfortunately, as mentioned in the original comment, automake fails QA in Prefix. I've attached the build log. I'll compare with other shebangs in other packages, but I'm thinking it might be possible to fix this by just patching the shebangs to be ${EPREFIX/usr/bin/perl instead of just /usr/bin/perl?
Created attachment 679071 [details] attr ebuild from bug 644048
Created attachment 679074 [details] build log for automake in RAP Prefix
Ok, can you post the diff between your version of the ebuild and the one in the tree? If you're modifying configure.ac, try and see if you can easily apply the matching fix to configure, that way you don't need to eautoreconf, and make the patch suitable during bootstrap.
Diff at the bottom of the comment.. The patch is the one in bug 644048. It modifies libattr/Makemodule.am. I'm not sure how that fits in the build process. Makefile.in lists libattr/Makemodule.am as a target, see line 745: > $(srcdir)/doc/Makemodule.am $(srcdir)/examples/Makemodule.am $(srcdir)/include/Makemodule.am $(srcdir)/libattr/Makemodule.am $(srcdir)/libmisc/Makemodule.am $(srcdir)/man/Makemodule.am $(srcdir)/man/man1/Makemodule.am $(srcdir)/man/man3/Makemodule.am $(srcdir)/test/Makemodule.am $(srcdir)/tools/Makemodule.am $(am__empty): I don't know how not to trigger autotools here. > $ diff -aur gentoo/sys-apps/attr/attr-2.4.48-r4.ebuild local/sys-apps/attr/attr-2.4.48-r5.ebuild > --- gentoo/sys-apps/attr/attr-2.4.48-r4.ebuild 2020-11-23 12:09:16.000000000 -0500 > +++ local/sys-apps/attr/attr-2.4.48-r5.ebuild 2020-12-21 20:47:09.896615601 -0500 > @@ -3,7 +3,7 @@ > > EAPI=7 > > -inherit flag-o-matic libtool toolchain-funcs multilib-minimal usr-ldscript > +inherit autotools flag-o-matic libtool toolchain-funcs multilib-minimal usr-ldscript > > DESCRIPTION="Extended attributes tools" > HOMEPAGE="https://savannah.nongnu.org/projects/attr" > @@ -19,6 +19,7 @@ > PATCHES=( > "${FILESDIR}/${P}-perl-5.26.patch" > "${FILESDIR}/${P}-switch-back-to-syscall.patch" > + "${FILESDIR}/${P}-use-asm-symver.patch" > ) > > pkg_setup() { > @@ -30,6 +31,7 @@ > src_prepare() { > default > elibtoolize #580792 > + eautoreconf > } > > multilib_src_configure() { > @@ -62,7 +64,7 @@ > "${versions}" != *"ATTR_1.1"* || \ > "${versions}" != *"ATTR_1.2"* || \ > "${versions}" != *"ATTR_1.3"* || \ > - "${symbols}" != *"getxattr@ATTR_1.0"* ]] ; then > + "${symbols}" != *"FUNC"*"getxattr@ATTR_1.0"* ]] ; then > echo "# readelf -V ${lib}" > echo "${versions}" > echo "# readelf -sW ${lib}"
The trick is going to be diffing before/after of configure and friends when the changed m4 is applied. We'll need to mess with timestamps possibly to stop it from running autoconf anyway.
I'm new too both Gentoo and Prefix, so this might be naive, but wouldn't it be easier to make automake suitable for Prefix? It seems to happen relatively often that a patch triggers automake. Is there some fundamental issue with automake and prefix?
Comment on attachment 679074 [details] build log for automake in RAP Prefix Do you have PERL set in your environment? Odd enough, also grep, install, etc. is found from outside the prefix. if I emerge automake, I see things like checking for perl... /Library/Gentoo-HighSierra/usr/bin/perl checking for tex... no checking for yacc... yacc checking for lex... lex checking whether autoconf is installed... yes checking whether autoconf works... yes checking whether autoconf is recent enough... yes checking whether ln works... yes checking for grep that handles long lines and -e... /Library/Gentoo-HighSierra/usr/bin/grep checking for egrep... /Library/Gentoo-HighSierra/usr/bin/grep -E checking for fgrep... /Library/Gentoo-HighSierra/usr/bin/grep -F configure: will now look for a sturdy POSIX shell, for our testsuite checking for sh... /Library/Gentoo-HighSierra/usr/bin/sh do you use the startprefix script?
Oh, sorry, wasn't clear enough. I can build automake in my non-RAP prefix, when I use the stratprefix script. However, the error happens when I try to bootstrap my RAP prefix. Basically, I added a sys-devel/automake just above the sys-apps/attr package in the stage3 bootstrapping portion of the boostrap_prefix.sh script. There, I can't use the startprefix script yet.
Right, so this is a bootstrap problem, and you should go with a patch that avoids the need for autoreconf/automake, because this is too early in the process to get things neatly in order. See comment #12, often it's also possible to do the required change to configure by hand, which makes it smaller in size, but first we need to establish what the necessary change is.
I believe my issue was a duplicate of bug 754753. The versions and symbols that the ebuild output when it fails were actually blank lines. That was due to readelf trying to load libdebuginfod, which is available on the host, but not in the EPREFIX, apparently. I was able to get attr-2.4.48 to compile by hardcoding the readelf binary in the ebuild, see the snippet below: ># Sanity check until we track down why this is happening. #644048 >local lib="${ED}/usr/$(get_libdir)/libattr.so.1" >if [[ -e ${lib} ]] ; then > local versions=$(${EPREFIX}/tmp/bin/x86_64-pc-linux-gnu-readelf -V "${lib}") # <--- hardcoded readelf > local symbols=$(${EPREFIX}/tmp/bin/x86_64-pc-linux-gnu-readelf -sW "${lib}") # <--- hardcoded readeld > if [[ "${versions}" != *"ATTR_1.0"* || \ > "${versions}" != *"ATTR_1.1"* || \ > "${versions}" != *"ATTR_1.2"* || \ > "${versions}" != *"ATTR_1.3"* || \ > "${symbols}" != *"FUNC"*"getxattr@ATTR_1.0"* ]] ; then > echo "# readelf -V ${lib}" > echo "${versions}" > echo "# readelf -sW ${lib}" > echo "${symbols}" > die "symbol version sanity check failed; please comment on https://bugs.gentoo.org/644048" > else > einfo "${lib} passed symbol checks" > fi >fi I also modified the patch to modify Makefile.in instead of Makemodules.am. I believe Makefile.in is modified by configure, not configure.ac, so eautoreconf is not necessary. I've attached the patch. I tried compiling libelf (this is the package that provides libdebuginfod on Arch, not sure on Gentoo though), but I got another autotools related error, which I haven't explored yet.
Created attachment 680314 [details, diff] symver patch without autoreconf
this actually appears to be a dup of 754753 *** This bug has been marked as a duplicate of bug 754753 ***
