| Summary: | >=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) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | tt_1 <herrtimson> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | base-system, cross, firefly_dude0k, hasso.tepper, whissi |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 680200 | ||
| Attachments: |
autoconf.out log file
emerge --info from cross-emerge PATCH: Reorder autotool arguments failed autoconf with eclass.patch from #11 temp folder of spidermonkey:60 temp folder of firefox-65.0.2 temp folder of glib-2.58.3 PATCH: Reorder autotool arguments (r1) PATCH: Reorder autotool arguments (r2) compressed tmp dir from spidermonkey config.log Patch against autotools.eclass and Firefox |
||
|
Description
tt_1
2019-03-13 10:05:46 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? Created attachment 568966 [details]
emerge --info from cross-emerge
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@ 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. Related to bug #677002? (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. (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? Forget my previous comment, I bypassed autoconf wrapper. (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. ;) Created attachment 569550 [details, diff]
PATCH: Reorder autotool arguments
Please apply the following eclass patch and test.
(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. 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...? (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. 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.
Created attachment 569582 [details]
failed autoconf with eclass.patch from #11
(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? Created attachment 569584 [details]
temp folder of spidermonkey:60
here's the complete folder with all of the logs for spidermonkey
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
> $@ 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... 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)
OK, the empty argument is causing the trouble,
> libtoolize: error: unknown additional arguments: ''
Created attachment 569602 [details, diff]
PATCH: Reorder autotool arguments (r1)
Please try the updated patch.
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).
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
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.
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.
(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! *** Bug 680200 has been marked as a duplicate of this bug. *** 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? (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 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 (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. @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? closing in favour of spidermonkey:78, which has the fix included |
