I decided to try to cross-compile Firefox, and the first problem is due to this in the autoconf log. (It means the -l argument must go before the file name.) $ cat /var/tmp/portage/www-client/firefox-73.0.1/temp/autoconf-1.out ***** autoconf ***** ***** PWD: /var/tmp/portage/www-client/firefox-73.0.1/work/firefox-73.0.1/js/src ***** autoconf old-configure.in -l /usr/powerpc-gentoo-linux-gnu/usr/share/aclocal Usage: autoconf [-h] [--help] [-m dir] [--macrodir=dir] [-l dir] [--localdir=dir] [--version] [template-file] Reproducible: Always Steps to Reproduce: 1. Run "emerge firefox" with a sysroot configuration Actual Results: The build fails with the above log. Expected Results: It should build (or at least make it to configuration). This change makes this particular package work, but I don't know if anything depends on the existing argument ordering. --- eclass/autotools.eclass +++ eclass/autotools.eclass @@ -512,7 +512,7 @@ fi if ${m4flags} ; then - set -- "${1}" $(autotools_m4dir_include) "${@:2}" $(autotools_m4sysdir_include) + set -- "${1}" $(autotools_m4dir_include) $(autotools_m4sysdir_include) "${@:2}" fi # If the caller wants to probe something, then let them do it directly.
yes, this is known bug for cross compiling firefox and friends, including spidermonkey standalone and thunderbird. The problem is along these lines in the ebuilds: # Must run autoconf in js/src cd "${S}"/js/src || die eautoconf old-configure.in while the mozilla documentation says to directly run autoconf-2.13 from within js/src. I don't really understand why it is important to use eautoconf here. You might want to read the original bug: https://bugs.gentoo.org/680210 so yeah, this is most likely a duplicate of 680210.
Sorry, I didn't see the spidermonkey bugs beforehand. It looks like bug #680210 has more going on in it, but this specific problem is noted there, so I'd be okay with closing this as a duplicate if just fixing the argument ordering isn't going to happen.
For what it's worth, I've been building several hundred packages for the last couple weeks with this fix applied, and I have not encountered a problem with it.
The change makes sense in itself but I actually think autotools_m4sysdir_include should go away entirely for reasons I have explained in #677002. I'd do it right now but no one replied and I'd like some agreement first. (slyfox: hint! hint!)
(In reply to James Le Cuirot from comment #4) > The change makes sense in itself but I actually think > autotools_m4sysdir_include should go away entirely for reasons I have > explained in #677002. > I'd do it right now but no one replied and I'd like some agreement first. (slyfox: hint! hint!) base-system@ maintains the eclass. They should get an authoritative answer. If you get nothing just go ahead and do it :)
(In reply to James Le Cuirot from comment #4) > The change makes sense in itself but I actually think > autotools_m4sysdir_include should go away entirely for reasons I have > explained in #677002. I'd do it right now but no one replied and I'd like > some agreement first. (slyfox: hint! hint!) Well, while that gets sorted out why don't we commit David's patch?
Right, I don't see how re-ordering the arguments would make things any worse. A "better" solution can always be implemented later. I'll push the patch tomorrow if there's no other objection.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=53678d996f4fda6eff08e5eeed3a518004a8e1dc commit 53678d996f4fda6eff08e5eeed3a518004a8e1dc Author: David Michael <fedora.dm0@gmail.com> AuthorDate: 2020-03-13 18:23:48 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-03-15 18:46:11 +0000 autotools.eclass: reorder sysroot M4 include dir option The old autoconf-2.13 version requires options to be specified before the file name argument, so packages with WANT_AUTOCONF="2.1" would fail to build in a sysroot with the -l option at the end. Closes: https://bugs.gentoo.org/710792 Signed-off-by: David Michael <fedora.dm0@gmail.com> Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/autotools.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
The bug has been referenced in 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(-)