Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 680210 - >=dev-lang/spidermonkey:52 cross-compile fail on eautoconf: old-configure.in is not last parameter when ac-wrapper.sh calls autoconf (also affected: all versions of firefox, thunderbird and seamonkey)
Summary: >=dev-lang/spidermonkey:52 cross-compile fail on eautoconf: old-configure.in ...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks: 680200
  Show dependency tree
 
Reported: 2019-03-13 10:05 UTC by tt_1
Modified: 2020-09-20 14:34 UTC (History)
5 users (show)

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


Attachments
autoconf.out log file (autoconf.out,350 bytes, text/plain)
2019-03-13 10:05 UTC, tt_1
Details
emerge --info from cross-emerge (emerge-info,4.95 KB, text/plain)
2019-03-13 10:22 UTC, tt_1
Details
PATCH: Reorder autotool arguments (bug680210.patch,1006 bytes, patch)
2019-03-17 22:05 UTC, Thomas Deutschmann
Details | Diff
failed autoconf with eclass.patch from #11 (autoconf-1.out,255 bytes, text/plain)
2019-03-18 07:54 UTC, tt_1
Details
temp folder of spidermonkey:60 (spidermonkey_temp.tar.bz2,75.98 KB, application/x-bzip)
2019-03-18 09:46 UTC, tt_1
Details
temp folder of firefox-65.0.2 (firefox_temp.tar.bz2,47.41 KB, application/x-bzip)
2019-03-18 09:47 UTC, tt_1
Details
temp folder of glib-2.58.3 (glib-temp.tar.bz2,45.72 KB, application/x-bzip)
2019-03-18 12:01 UTC, tt_1
Details
PATCH: Reorder autotool arguments (r1) (bug680210-r1.patch,1.07 KB, patch)
2019-03-18 14:50 UTC, Thomas Deutschmann
Details | Diff
PATCH: Reorder autotool arguments (r2) (bug680210-r2.patch,1.67 KB, patch)
2019-03-18 17:35 UTC, Thomas Deutschmann
Details | Diff
compressed tmp dir from spidermonkey (spidermonkey52-temp.tar.bz2,35.30 KB, application/x-bzip)
2019-03-18 21:22 UTC, tt_1
Details
config.log (spidermonkey-config.log,17.96 KB, text/x-log)
2019-03-18 21:25 UTC, tt_1
Details
Patch against autotools.eclass and Firefox (autotools-class-firefox.patch,3.09 KB, patch)
2019-03-18 22:53 UTC, James Le Cuirot
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tt_1 2019-03-13 10:05:46 UTC
Created attachment 568964 [details]
autoconf.out log file

this affects spidermonkey:60 as well, and possibly firefox/thunderbird/seamonkey

emerge-armv7a-unknown-linux-gnueabihf -av spidermonkey:52

>>> Emerging (1 of 1) dev-lang/spidermonkey-52.9.1_pre1::gentoo for /usr/armv7a-unknown-linux-gnueabihf/
 * mozjs-52.9.1pre1.tar.bz2 BLAKE2B SHA512 size ;-) ...                                                                                                                          [ ok ]
 * spidermonkey-52.0-patches-0.tar.xz BLAKE2B SHA512 size ;-) ...                                                                                                                [ ok ]
>>> Unpacking source...
>>> Unpacking mozjs-52.9.1pre1.tar.bz2 to /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-52.9.1_pre1/work
>>> Unpacking spidermonkey-52.0-patches-0.tar.xz to /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-52.9.1_pre1/work
>>> Source unpacked in /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-52.9.1_pre1/work
>>> Preparing source in /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-52.9.1_pre1/work/mozjs-52.9.1pre1 ...
 * Applying patches from /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-52.9.1_pre1/work/spidermonkey ...
 *   0003-build-Fix-library-install-name-on-macOS.patch ...                                                                                                                      [ ok ]
 *   0004-build-Copy-headers-on-install-instead-of-symlinking.patch ...                                                                                                          [ ok ]
 *   0006-Disable-MOZ_GLUE_IN_PROGRAM-in-stand-alone-builds-on.patch ...                                                                                                         [ ok ]
 *   0009-build-Include-configure-script-be-nicer-about-option.patch ...                                                                                                         [ ok ]
 * Applying moz38-dont-hardcode-libc-soname.patch ...                                                                                                                            [ ok ]
 * Applying spidermonkey-52.0-fix-alpha-bitness.patch ...                                                                                                                        [ ok ]
 * Running autoconf old-configure.in -l /usr/armv7a-unknown-linux-gnueabihf/usr/share/aclocal ...                                                                                [ !! ]

 * Failed Running autoconf !
 * 
 * Include in your bugreport the contents of:
 * 
 *   /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-52.9.1_pre1/temp/autoconf.out
Comment 1 tt_1 2019-03-13 10:20:28 UTC
Now, the official documentation: https://developer.mozilla.org/de/docs/SpiderMonkey/Build_Documentation says to run autoconf-2.13(!) from within js/src 

the ebuild does the following in src_prepare:

	cd "${S}"/js/src || die
	eautoconf old-configure.in
	eautoconf

now, it seems that eautoconf is the nickname portage does use for executing /usr/bin/autoconf. Since this is a mere symlink to the ac-wrapper.sh in /usr/lib64, which aims to choose the correct version of autoconf to use, it seems to fail here at some point. 

Since the official documentation says to run only autoconf-2.13 from within js/src, I wonder which intention the ebuild has to run eautoconf old-configure.in
in the first place? 

And, are there any consequences of replacing the call to eautoconf with autoconf-2.13 at all? I gave it a quick go on my amd64 workstation, and it at least didn't break the compile, so it might be worth to investigate further?
Comment 2 tt_1 2019-03-13 10:22:53 UTC
Created attachment 568966 [details]
emerge --info from cross-emerge
Comment 3 Ian Stakenvicius (RETIRED) gentoo-dev 2019-03-13 19:23:21 UTC
Hm.  So according to autoconf.out the order of operations needs to be reversed -- that old-configure.in template file needs to come last.

This will require a patch to sys-devel/autoconf-wrapper it looks like...  CC'ing base-system@
Comment 4 James Le Cuirot gentoo-dev 2019-03-15 22:39:00 UTC
Just ran into this myself.

I don't think autoconf-wrapper has anything to do with it, /usr/bin/autoconf just passes the arguments straight through as you would expect.

The problem is in autotools_run_tool. It deliberately puts $(autotools_m4sysdir_include) at the end, after any given arguments, but it doesn't check whether these arguments start with a - or not.

However, it's debatable whether eautoconf is supposed to take any non-option arguments. These are the only packages in the whole tree that pass one and note how eautoconf checks specifically for configure.ac or configure.in first. Is it possible to rename old-configure.in?

On a closely related note, you're also calling eautoreconf (not eautoconf!) with old-configure.in and that's invalid. The eclass says this doesn't take any arguments and indeed, it does nothing with them.
Comment 5 Sergei Trofimovich gentoo-dev 2019-03-16 10:18:13 UTC
Related to bug #677002?
Comment 6 James Le Cuirot gentoo-dev 2019-03-16 16:35:28 UTC
(In reply to Sergei Trofimovich from comment #5)
> Related to bug #677002?

It's in the same area of code but it's not really related beyond that.
Comment 7 Thomas Deutschmann gentoo-dev Security 2019-03-17 18:58:42 UTC
(In reply to James Le Cuirot from comment #4)
> On a closely related note, you're also calling eautoreconf (not eautoconf!)
> with old-configure.in and that's invalid. The eclass says this doesn't take
> any arguments and indeed, it does nothing with them.

Where are we doing this? I cannot find a call to _eautoreconf_, only eautoconf.

Renaming is not an option.

> The problem is in autotools_run_tool. It deliberately puts $(autotools_m4sysdir_include) at the end, after any given arguments, but it doesn't check whether these arguments start with a - or not.

From my testing the problem is that "-l" is an unsupported parameter in autoconf.

I am getting the same when I try to get verbose output when I change ebuild from

> eautoconf old-configure.in

into

> eautoconf -v old-configure.in

However, "-v" is mentioned in `man autoconf`.

When I use the long option (--verbose) instead, it's working.

But "-l" seems to be an invalid parameter... where is this coming from?
Comment 8 Thomas Deutschmann gentoo-dev Security 2019-03-17 19:29:55 UTC
Forget my previous comment, I bypassed autoconf wrapper.
Comment 9 James Le Cuirot gentoo-dev 2019-03-17 21:50:31 UTC
(In reply to Thomas Deutschmann from comment #7)
> (In reply to James Le Cuirot from comment #4)
> > On a closely related note, you're also calling eautoreconf (not eautoconf!)
> > with old-configure.in and that's invalid. The eclass says this doesn't take
> > any arguments and indeed, it does nothing with them.
>
> Renaming is not an option.

I was in the middle of writing about what needs to be done to make eautoconf accept filename arguments but then I realised something. Your call isn't actually changing anything! When autoconf is called with a filename, it writes to stdout. You don't see that here because the eclass captures the output and writes it to a log file under ${T}.

I can see from js/src/configure that it's referencing old-configure in the same directory but that seemingly never gets created so I don't know how it's supposed to work.
 
> Where are we doing this? I cannot find a call to _eautoreconf_, only
> eautoconf.

Sorry, I'm coming at this from Firefox. You're also doing this in SeaMonkey and Thunderbird. Again, these are the only packages in the entire tree that have this.

In the Firefox case, the top-level old-configure is already present in the tarball but even though you patch old-configure.in, old-configure never gets rewritten. eautoreconf ignores the argument but even if it passed the argument through, it would still only write to stdout.

So you either need significant work to make eautoconf accept file arguments, rethink your approach, or just remove these bits from the ebuilds because you never noticed that they did nothing. ;)
Comment 10 Thomas Deutschmann gentoo-dev Security 2019-03-17 22:05:54 UTC
Created attachment 569550 [details, diff]
PATCH: Reorder autotool arguments

Please apply the following eclass patch and test.
Comment 11 James Le Cuirot gentoo-dev 2019-03-17 22:13:32 UTC
(In reply to Thomas Deutschmann from comment #10)
> Created attachment 569550 [details, diff] [details, diff]
> PATCH: Reorder autotool arguments
> 
> Please apply the following eclass patch and test.

Unless I'm mistaken, this doesn't address the fact these these calls only write to stdout. Timing suggests you wrote this patch while I was writing the above message.
Comment 12 Thomas Deutschmann gentoo-dev Security 2019-03-17 22:32:41 UTC
Yes, I created the patch while you was adding your last comment.

I don't have a crossdev environment at the moment so I cannot really test.  The only thing I could test was what will happen if you pass options to "eautoconf" _after_ template-file argument. The result matches the original failure:

autoconf is just failing because options must be set _before_ template-file argument.

The patch will make sure that template-file will be set last.

This will make eautoconf call pass.

Are you suggesting that we shouldn't patch autotools eclass at all because only a few Mozilla packages (no other packages!) are passing arguments/options to eautoconf and because this doesn't really _do anything_ we should just get rid of those calls...?
Comment 13 James Le Cuirot gentoo-dev 2019-03-17 22:57:20 UTC
(In reply to Thomas Deutschmann from comment #12)
> I don't have a crossdev environment at the moment so I cannot really test. 

To be clear, these calls do nothing for native builds too. If you run src_prepare as normal, you can see that old-configure's timestamp is unchanged and js/src/old-configure is never created.

> Are you suggesting that we shouldn't patch autotools eclass at all because
> only a few Mozilla packages (no other packages!) are passing
> arguments/options to eautoconf and because this doesn't really _do anything_
> we should just get rid of those calls...?

Kind of. I don't know how important it is that you regenerate these files. Perhaps not very important if you never noticed this before.

However, I have just noticed that autoconf has -o option and the openafs package uses this along with a filename argument. Now fixing the eclass doesn't seem so hard.

I just tried your patch but it doesn't work. I'll see if I can fix it up. Even with the -o option, eautoreconf not accepting arguments remains an issue but I guess the simplest solution would be to use eautoconf against the top-level old-configure.in too. Having eautoreconf accept arguments would be confusing as it calls several different tools.
Comment 14 James Le Cuirot gentoo-dev 2019-03-17 23:17:19 UTC
Aww, I thought I was being clever by doing it like this.

if ${m4flags} ; then
	local tool=$1
	shift
	set -- "${tool}" $(autotools_m4dir_include) "${@##[^-]*}" $(autotools_m4sysdir_include) "${@##-*}"
fi

But of course the options need to stay paired with their associated values.
Comment 15 tt_1 2019-03-18 07:54:04 UTC
Created attachment 569582 [details]
failed autoconf with eclass.patch from #11
Comment 16 Thomas Deutschmann gentoo-dev Security 2019-03-18 09:38:07 UTC
(In reply to tt_1 from comment #15)
> Created attachment 569582 [details]
> failed autoconf with eclass.patch from #11

Can you please show us eclass-debug.log, too?
Comment 17 tt_1 2019-03-18 09:46:37 UTC
Created attachment 569584 [details]
temp folder of spidermonkey:60

here's the complete folder with all of the logs for spidermonkey
Comment 18 tt_1 2019-03-18 09:47:57 UTC
Created attachment 569586 [details]
temp folder of firefox-65.0.2

and, if you want to have a look at it, the same for firefox

it inherits spidermonkey in itself, so should be the same cause
Comment 19 Thomas Deutschmann gentoo-dev Security 2019-03-18 09:56:40 UTC
> $@ before reordering of arguments: autoconf old-configure.in -l /usr/armv7a-unknown-linux-gnueabihf/usr/share/aclocal
> $@ after reordering of arguments: autoconf -l /usr/armv7a-unknown-linux-gnueabihf/usr/share/aclocal old-configure.in
and
> $@ before reordering of arguments: autoconf -l /usr/armv7a-unknown-linux-gnueabihf/usr/share/aclocal
> $@ after reordering of arguments: autoconf -l /usr/armv7a-unknown-linux-gnueabihf/usr/share/aclocal

I see nothing wrong here which should cause

> autoconf: : No such file or directory

However, the "autoconf: : " looks weird. Maybe

> set -- "${_at_command}" "${_at_args[@]}" "${_at_file}"

is causing problems when _at_args or _at_file is empty...
Comment 20 tt_1 2019-03-18 12:01:57 UTC
Created attachment 569590 [details]
temp folder of glib-2.58.3

I forgot to revert the patch when rebuilding world after gcc/glibc upgrade, it might give you some more insight? 

(native amd64 compile)
Comment 21 Thomas Deutschmann gentoo-dev Security 2019-03-18 14:29:17 UTC
OK, the empty argument is causing the trouble,

> libtoolize:   error: unknown additional arguments: ''
Comment 22 Thomas Deutschmann gentoo-dev Security 2019-03-18 14:50:31 UTC
Created attachment 569602 [details, diff]
PATCH: Reorder autotool arguments (r1)

Please try the updated patch.
Comment 23 Thomas Deutschmann gentoo-dev Security 2019-03-18 17:35:56 UTC
Created attachment 569608 [details, diff]
PATCH: Reorder autotool arguments (r2)

Patch updated: "eautoreconf foo.in" will now actually write new foo script (2.1 only, newer versions must use "-o" option).
Comment 24 tt_1 2019-03-18 21:22:39 UTC
Created attachment 569730 [details]
compressed tmp dir from spidermonkey

with your -r2 patch, the compile of glib-2.58.3 is fine. 

but the cross-compile of spidermonkey does fail
Comment 25 tt_1 2019-03-18 21:25:06 UTC
Created attachment 569732 [details]
config.log

here's the config.log from configure

it seems to choose x86_64-pc-linux-gnu over the cross-compiler? 

with the -r2 patch reverted, it's all back to the failed eautoconf cmd from the initial postings.
Comment 26 James Le Cuirot gentoo-dev 2019-03-18 22:53:35 UTC
Created attachment 569742 [details, diff]
Patch against autotools.eclass and Firefox

How about this? I think it's simpler and safer. It respects spaces and doesn't assume any file extensions. I've used the existing --at-output option to write to a file.
Comment 27 Thomas Deutschmann gentoo-dev Security 2019-03-18 23:53:38 UTC
(In reply to tt_1 from comment #25)
> Created attachment 569732 [details]
> config.log
> 
> here's the config.log from configure
> 
> it seems to choose x86_64-pc-linux-gnu over the cross-compiler? 
> 
> with the -r2 patch reverted, it's all back to the failed eautoconf cmd from
> the initial postings.

Your new error is

> ERROR: Host C compiler target CPU (x86_64) does not match --host CPU (armv7a)

This has nothing to do with this bug.


@ James:

Interesting, looks clever. First I thought it will clash with error handling but --at-output will make it work. I have to do more tests, thanks!
Comment 28 Jory A. Pratt gentoo-dev 2019-03-31 20:50:08 UTC
*** Bug 680200 has been marked as a duplicate of this bug. ***
Comment 29 tt_1 2019-05-11 21:26:38 UTC
hey there, I managed to hack around the compiler missdetection. Not ready for the tree yet, but I'll try to sort it out. 

Which means I'm able to test the patches for the bug in eautoconf. Which of your approaches is the most promissing?
Comment 30 James Le Cuirot gentoo-dev 2019-05-11 21:56:23 UTC
(In reply to tt_1 from comment #29)
> Which means I'm able to test the patches for the bug in eautoconf. Which of
> your approaches is the most promissing?

I still stand by mine. I think you'll need to replace the spidermonkey eautoconf lines with:

eautoconf --at-output --at-file old-configure.in > old-configure
Comment 31 tt_1 2019-05-11 22:20:55 UTC
still complaining:

>>> Source configured.
>>> Compiling source in /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-60.5.2_p0-r2/work/mozjs-60.5.2 ...
make -j12 MOZ_OPTIMIZE_FLAGS= MOZ_DEBUG_FLAGS= HOST_OPTIMIZE_FLAGS= MODULE_OPTIMIZE_FLAGS= MOZ_PGO_OPTIMIZE_FLAGS= 
make[1]: Entering directory '/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-60.5.2_p0-r2/work/mozjs-60.5.2/jsobj'
STOP!  /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-60.5.2_p0-r2/work/mozjs-60.5.2/js/src/old-configure.in has changed, and your configure is out of date.
Please rerun autoconf and re-configure your build directory.
To ignore this message, touch "/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-60.5.2_p0-r2/work/mozjs-60.5.2/js/src/configure",
but your build might not succeed.


maybe like this? 


<	eautoconf old-configure.in
<	eautoconf

>	eautoconf --at-output --at-file old-configure.in > old-configure
>	eautoreconf
Comment 32 James Le Cuirot gentoo-dev 2019-05-11 22:25:20 UTC
(In reply to tt_1 from comment #31)
> maybe like this? 
> 
> 
> <	eautoconf old-configure.in
> <	eautoconf
> 
> >	eautoconf --at-output --at-file old-configure.in > old-configure
> >	eautoreconf

Put eautoconf and eautoreconf the other way round. I wasn't sure whether this would need eautoreconf or not as firefox had it but spidermonkey didn't.
Comment 33 tt_1 2019-06-10 07:13:42 UTC
@whissi: I'm ccing you to ask what the status of this is? Is it possible to adopt the patch from James for the tree?
Comment 34 tt_1 2020-09-20 14:34:33 UTC
closing in favour of spidermonkey:78, which has the fix included