I've been doing various work with rockchip chromebooks and gentoo, and am basically looking for any packages which fail in some way or another when building the rootfs via crossdev. The first such issue I've ran into and am documenting is this one. Reproducible: Always Steps to Reproduce: 1. create a fresh chroot with a stage3 (don't want to mask issues due to packages being installed in BROOT), set ~arch, update, install crossdev 2. crossdev a 'real' cross-toolchain (unsure if this problem exists when going from say x86_64-pc-linux-gnu to x86_64-pc-linux-musl, for example). I've tested this with the following CHOSTs: aarch64-unknown-linux-gnu, aarch64-unknown-linux-musl, and armv7a-unknown-linux-musleabihf 3. set an appropriate profile for the cross-root. I used, respectively to the above CHOSTs: default/linux/arm64/17.0, default/linux/musl/arm64, and default/linux/arm/17.0/musl/armv7a 4. cross-emerge -1 =sys-libs/gdbm-1.18.1. This works in all of the above CHOST and profile combos. 5. cross-emerge -1 =sys-devel/gettext-0.19.8.1. This works in all of the above CHOST and profile combos. 6. cross-emerge -1 =sys-libs/gdbm-1.18.1. This fails, stating a that there is a "gettext infrastructure mismpatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.19" Similar issues appear to be present and worked around in several packages in the tree, including app-mobilephone/ganyremote-6.3.3, dev-util/bless-0.6.0-r{3,4}, kde-misc/kanyremote-6.4, and media-gfx/gliv-1.9.7. They all state they cribbed the fix from dev-util/bless, which in turn states it cribbed its fix from enlightenment.eclass (last-rited as of 2018-10-18).
Created attachment 563376 [details] armv7a-unknown-linux-musleabihf-emerge -1 sys-libs/gdbm This is after sys-devel/gettext has been emerged in the cross-root.
Created attachment 563378 [details] armv7a-unknown-linux-musleabihf-emerge --info
Created attachment 563380 [details] armv7a-unknown-linux-musleabihf-emerge --info sys-libs/gdbm
Created attachment 563382 [details] armv7a-unknown-linux-musleabihf-emerge --info sys-devel/gettext
To fix this we could implement the fix from the listed packages, but this seems to be a lot of duplicate work. Further investigation shows that each of the packages using the gettext hack from dev-libs/bliss from enlightenment.eclass also uses the autotools eclass. Its quite possible we could create a standalone eclass for fixing up these kinds of issues with something like egettextize or the like.
Exact build failure from the above linked build.log is: > >>> Compiling source in /usr/armv7a-unknown-linux-musleabihf/tmp/portage/sys-libs/gdbm-1.18.1/work/gdbm-1.18.1 ... > * .arm: running multilib-minimal_abi_src_compile > make -j16 > make all-recursive > make[1]: Entering directory '/usr/armv7a-unknown-linux-musleabihf/tmp/portage/sys-libs/gdbm-1.18.1/work/gdbm-1.18.1-.arm' > Making all in po > make[2]: Entering directory '/usr/armv7a-unknown-linux-musleabihf/tmp/portage/sys-libs/gdbm-1.18.1/work/gdbm-1.18.1-.arm/po' > *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.19 > make[2]: *** [Makefile:181: check-macro-version] Error 1 > make[2]: Leaving directory '/usr/armv7a-unknown-linux-musleabihf/tmp/portage/sys-libs/gdbm-1.18.1/work/gdbm-1.18.1-.arm/po' > make[1]: *** [Makefile:460: all-recursive] Error 1 > make[1]: Leaving directory '/usr/armv7a-unknown-linux-musleabihf/tmp/portage/sys-libs/gdbm-1.18.1/work/gdbm-1.18.1-.arm' > make: *** [Makefile:392: all] Error 2 The 'fix' used in the listed packages is (excerpt from dev-util/bless): > pkg_setup() { > # Stolen from enlightenment.eclass > cp $(type -p gettextize) "${T}/" || die "Could not copy gettextize" > sed -i -e 's:read dummy < /dev/tty::' "${T}/gettextize" > ... > } > > src_prepare() { > einfo "Running gettextize -f --no-changelog..." > ( "${T}/gettextize" -f --no-changelog > /dev/null ) || die "gettextize failed" > .... > }
The build fails because durint aclocal run m4/po.m4 does not get into aclocal.m4 I think it happens because autotools.eclass accidentally overrides default '-I m4' argument with the following parameter: aclocal -I /usr/armv7a-unknown-linux-gnueabihf/usr/share/aclocal If I run aclocal as: aclocal --system-acdir=/usr/armv7a-unknown-linux-gnueabihf/usr/share/aclocal aclocal.m4 get proper contents and refers to m4/po.m4. I think -I injection happens here: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/autotools.eclass#n621 Reassigning to autotools.eclass maintainer.
Please CC cross@gentoo.org rather than crossdev@gentoo.org on issues like these. It took me a while to figure this out but I think slyfox is kind of right. The m4 directory is automatically included but -I directories are prepended in front of this. configure.ac is hardcoded to use gettext 0.18 so using po.m4 from 0.19 breaks it. If you change the ebuild to call "AT_M4DIR=m4 eautoreconf" then it works as it explicitly adds -I m4 but I don't think that's the right solution. It also blows up with -I /usr/share/aclocal. This only affects cross because we have set SYSROOT and that causes the eclass to add the -I argument. vapier added this SYSROOT feature and I'm wondering whether it is really necessary, at least in the context of EAPI 7. It's debatable but I think aclocal files are build system dependencies that belong in BDEPEND. Before EAPI 7, it gets a little messy. cross-emerge defaults to throwing DEPEND away entirely. Was vapier relying on RDEPEND to install these files to SYSROOT? I don't think --system-acdir is the right answer because you can only set it once and that means that nothing from /usr/share/aclocal will ever be used. As I just said, these are build system dependencies so it doesn't make sense to always look for them within SYSROOT. So I guess the options are: 1. Don't add an -I option for SYSROOT in EAPI 7. 2. Don't add an -I option for SYSROOT at all, removing vapier's feature. 3. Use the AC_CONFIG_MACRO_DIR value from configure.ac to explicitly add another -I option in front of the SYSROOT one.
There are a few other options to have multiple directories for --system-acdir: * The ACLOCAL_PATH environment variable (since automake-1.11.2) * The dirlist file (since automake-1.7) While ACLOCAL_PATH is an option, I'd rather not use it since I feel like the environment should be available to the end user. A file at system-acdir/dirlist can list additional directories to append to the search path.[1] This could be written to the sysroot aclocal containing just /usr/share/aclocal to chain both of them, but that file probably shouldn't be packaged to keep it out of binpkgs etc. Also, the documentation mentions that the ordering of system-acdir and dirlist could change in the future. Because of this, I think the best use of this option may be to have --system-acdir="${T}/aclocal" where $T/aclocal/dirlist contains $SYSROOT/usr/share/aclocal and /usr/share/aclocal to be future-proof. [1] https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html#Modifying-the-Macro-Search-Path_003a-dirlist
(In reply to James Le Cuirot from comment #8) > vapier added this SYSROOT feature and I'm wondering whether it is really > necessary, at least in the context of EAPI 7. It's debatable but I think > aclocal files are build system dependencies that belong in BDEPEND. Before > EAPI 7, it gets a little messy. cross-emerge defaults to throwing DEPEND > away entirely. Was vapier relying on RDEPEND to install these files to > SYSROOT? this is fairly trivial to disprove. look at what installs into /usr/share/aclocal. it's libraries installing their m4 files to find themselves. packages linking against those libraries and using their m4 files (which is the norm) will now need all of their DEPENDs duplicated in BDEPEND, but only if regenerating autotools. some projects, like autoconf-archive, are easy to reason about and say they belong in BDEPEND only. but freetype ? curl ? gtk+ ? for example, if a package builds against curl, it goes into DEPEND+RDEPEND, and hence SYSROOT. if a package uses curl's LIBCURL_CHECK_CONFIG, it needs curl's libcurl.m4, which it has in SYSROOT. but if you drop that, it's not in BDEPEND (/), so it's not going to be found.
(In reply to SpanKY from comment #10) > (In reply to James Le Cuirot from comment #8) > > vapier added this SYSROOT feature and I'm wondering whether it is really > > necessary, at least in the context of EAPI 7. It's debatable but I think > > aclocal files are build system dependencies that belong in BDEPEND. Before > > EAPI 7, it gets a little messy. cross-emerge defaults to throwing DEPEND > > away entirely. Was vapier relying on RDEPEND to install these files to > > SYSROOT? > > this is fairly trivial to disprove. look at what installs into > /usr/share/aclocal. it's libraries installing their m4 files to find > themselves. packages linking against those libraries and using their m4 > files (which is the norm) will now need all of their DEPENDs duplicated in > BDEPEND, but only if regenerating autotools. > > some projects, like autoconf-archive, are easy to reason about and say they > belong in BDEPEND only. but freetype ? curl ? gtk+ ? > > for example, if a package builds against curl, it goes into DEPEND+RDEPEND, > and hence SYSROOT. if a package uses curl's LIBCURL_CHECK_CONFIG, it needs > curl's libcurl.m4, which it has in SYSROOT. but if you drop that, it's not > in BDEPEND (/), so it's not going to be found. That's fair. When I wrote that, I hadn't noticed just how many packages drop files in there. Sam made broadly the same point, so we're going with David's --system-acdir suggestion rather than my own. I support this decision.
(In reply to James Le Cuirot from comment #11) don't sweat it. no one has ever accused autotools of being easy to use :p. i started a discussion upstream and they seem amenable to adding an --aclocal-path option that overrides $ACLOCAL_PATH. so we should just try switching to that as i think it gives us the semantics we want -- after -I but before /usr/share/aclocal. i don't think we really need to support users injecting their own ACLOCAL_PATH into the mix.
(In reply to SpanKY from comment #12) > (In reply to James Le Cuirot from comment #11) > > don't sweat it. no one has ever accused autotools of being easy to use :p. > > i started a discussion upstream and they seem amenable to adding an > --aclocal-path option that overrides $ACLOCAL_PATH. so we should just try > switching to that as i think it gives us the semantics we want -- after -I > but before /usr/share/aclocal. i don't think we really need to support > users injecting their own ACLOCAL_PATH into the mix. This sounds good to me, although my preference is we'd do the system acdir bit for now given it'll take time to work into a release. But sounds better than making a cheesy file for something which should be more elegant. Agreed, I'm not bothered about people injecting their own -- it's like /usr/local-level risk of contamination/breakage anyway. Will this cover ${BROOT}/usr/share/aclocal too, or would we need to pass this twice? I've talked myself into circles on whether it actually respects BROOT properly right now, tbh
It does respect BROOT now as the install prefix is hardcoded. Check /usr/bin/aclocal-* on a prefixed system.
(In reply to James Le Cuirot from comment #14) > It does respect BROOT now as the install prefix is hardcoded. Check > /usr/bin/aclocal-* on a prefixed system. oh right, duh. Now I've done it!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5593ef751758f5e45b470f678134b93dd6b17078 commit 5593ef751758f5e45b470f678134b93dd6b17078 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-14 19:21:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-22 22:22:23 +0000 autotools.eclass: use --system-acdir for aclocal We need to instruct aclocal that it might find macros in both ${BROOT} _and_ ${SYSROOT}. - A classic example within BROOT is autoconf-archive. - A classic example within SYSROOT is, say, libogg. A fair amount of codec software installs its own macro to help locating it (but this is in no ways limited to that genre/area). The correct position for a dependency like libogg is DEPEND, and yet the status quo doesn't mean that aclocal is obligated to check in ${ESYSROOT} which is where DEPEND-class dependencies are guaranteed to be installed. We can't rely on these being in BDEPEND -- in fact, most of the time, they won't be. If we wanted to rely on macros always being provided by BDEPEND, we'd have to duplicate a considerable number of dependencies in both BDEPEND + DEPEND, with the unnecessary cross-compilation that would entail too: it makes far more sense to just tell aclocal to look in the right place (an extra location). Bug: https://bugs.gentoo.org/710792 Closes: https://bugs.gentoo.org/677002 Closes: https://bugs.gentoo.org/738918 Thanks-to: David Michael <fedora.dm0@gmail.com> (for the suggestion) Thanks-to: James Le Cuirot <chewi@gentoo.org> (rubberducking & sounding board) Signed-off-by: Sam James <sam@gentoo.org> eclass/autotools.eclass | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=553191db3544b3c9960c47283329cb315649dfa3 commit 553191db3544b3c9960c47283329cb315649dfa3 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-12 02:53:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-22 22:21:15 +0000 autotools.eclass: don't inject -I${SYSROOT} to aclocal When -I${SYSROOT} is injected, it'll override the default of -Im4, which results in trying to install macros to ${SYSROOT} (a sandbox violation) when they can't be found. From aclocal(1): ``` -I DIR add directory to search list for .m4 files --install copy third-party files to the first -I directory ``` The first directory is normally -Im4 if anything, whereas when injected (when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so we try to copy macros to somewhere outside of the build directory). [We could drop this just for > EAPI 7, but I'm not sure there's much point there either. As Chewi observed in bug 677002, you can't assume they'll be present in ${SYSROOT} anyway, and frankly, the cross-compilation (and --root, --sysroot, and so on) situation is rather bleak for earlier EAPIs, which is why we did all that work for 7.] Bug: https://bugs.gentoo.org/710792 Closes: https://bugs.gentoo.org/677002 Closes: https://bugs.gentoo.org/738918 Thanks-to: James Le Cuirot <chewi@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> eclass/autotools.eclass | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
