Fri 28 Jul 2017 06:51:54 PM UTC, comment #11:
Thanks, with the fix libsndfile now gets built.
Closing report as "fixed" and adapting title for future reference
|
Fri 28 Jul 2017 05:02:53 PM UTC, comment #10:
Pushed http://hg.octave.org/mxe-octave/rev/2db2282dfe9a
|
Fri 28 Jul 2017 02:57:47 PM UTC, comment #9:
Thanks Mike, so it looks like the regex had better be fixed.
Doesn't "deprecated" in due time automagically morph into "illegal" anyway? :-)
|
Fri 28 Jul 2017 02:56:06 PM UTC, comment #8:
Here is the relevant Automake upstream commit
https://git.savannah.gnu.org/cgit/automake.git/commit/?id=13f00eb4493c217269b76614759e452d8302955e
|
Fri 28 Jul 2017 02:53:39 PM UTC, comment #7:
Ok, according to the Automake NEWS file:
So Philip probably has Perl 5.26 or newer, not necessarily Perl 6 (that was just a guess). My system is still at Perl 5.24.
We could continue using Automake 1.11 and patch this one regex, which seems simple and safest, or try updating mxe-octave to new Autoconf / Automake, which may break some builds of other packages.
|
Fri 28 Jul 2017 02:45:11 PM UTC, comment #6:
Yes, we use identical autotools in mxe-octave, but Automake is a perl program, and it assumes the host OS perl interpreter is sufficient.
It seems obvious that the difference is this warning, which still allows Automake to run:
"Unescaped left brace in regex is deprecated, passed through in regex"
versus this error message, which causes Automake to fail:
"Unescaped left brace in regex is illegal here in regex;"
These messages are coming from perl itself as it's parsing the Automake program. I'm guessing Philip's unstable system maybe has Perl 6, which doesn't seem to like Automake 1.11 (which is now 6 years old itself).
|
Fri 28 Jul 2017 01:52:07 PM UTC, comment #5:
shave was a valid option, but doesn't appear to be anymore - I'll remove it.
I've seen the scan_file warning on several packages before doing a quick check in my log files, it appears also on arpack, fontconfig, glpk, gnutls, libssh2 and others.
I believe that it should be using the autotools we provide as build_xxxx.mk so shouldnt be an issue with differing tools.
|
Fri 28 Jul 2017 01:18:16 PM UTC, comment #4:
Looks like the same error, but on my box the build breaks.
configure options are --enable-octave=defaut --enable-windows-64 --enable-devel-tools --enable-binary-packages
On my other build box (stable Mageia-5), where I also just run "hg -v pull && hg -v update" (27 csets rather than the 9 on my main box) libsndfile got built fine, with the same (error? warning?) message about scan_file()
So maybe Mageia-6 has more picky autotools; or maybe the error message about scan_file() is just a red herring (see my remark abut unstable Mageia-6).
Taking into account that on my other box the build continues, what to do with this bug? "works for me"?
BTW nitty-gritty dept: a bit lower in the log I see:
(and I also see it in your log).
Should this be "--disable-share" ?
|
Fri 28 Jul 2017 11:58:47 AM UTC, comment #3:
looking at the log on portaudio on my mxe build
but it continues with the build of libsndfile
|
Fri 28 Jul 2017 10:36:53 AM UTC, comment #2:
What configure options are using for mxe?
It builds ok on my fedora box, but I ooften do a complete rebuild of everything so if there was a comflict between some old stuff and new, I may not get it.
|
Fri 28 Jul 2017 07:50:44 AM UTC, comment #1:
FTR, this is after "hg pull && hg update" in an existing me-octave. So the same cross-compiler was used here.
Backing out the flac upgrade makes no difference.
I wonder if this is related to building on (unstable) Mageia-6. A while ago I couldn't cross-build Octave at all on the box in question; after a series of Mageia package upgrades it suddenly worked, yesterday there was another series of package upgrades.
|
Thu 27 Jul 2017 09:45:22 PM UTC, original submission:
|