Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 710792 - autotools.eclass: Firefox autoconf fails from option ordering in a sysroot
Summary: autotools.eclass: Firefox autoconf fails from option ordering in a sysroot
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-25 18:00 UTC by David Michael
Modified: 2022-01-22 22:22 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Michael 2020-02-25 18:00:36 UTC
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.
Comment 1 tt_1 2020-02-26 06:57:44 UTC
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.
Comment 2 David Michael 2020-02-26 14:41:46 UTC
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.
Comment 3 David Michael 2020-03-12 15:29:30 UTC
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.
Comment 4 James Le Cuirot gentoo-dev 2020-03-13 21:02:59 UTC
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!)
Comment 5 Sergei Trofimovich (RETIRED) gentoo-dev 2020-03-13 22:11:59 UTC
(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 :)
Comment 6 Matt Turner gentoo-dev 2020-03-15 01:06:18 UTC
(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?
Comment 7 Mike Gilbert gentoo-dev 2020-03-15 01:25:09 UTC
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.
Comment 8 Larry the Git Cow gentoo-dev 2020-03-15 18:46:33 UTC
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(-)
Comment 9 Larry the Git Cow gentoo-dev 2022-01-22 22:22:49 UTC
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(-)