Opened 21 months ago
Closed 19 months ago
#24903 closed defect (fixed)
optional package autotools fail to build
Reported by: | vdelecroix | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-8.2 |
Component: | packages: optional | Keywords: | |
Cc: | mkoeppe | Merged in: | |
Authors: | Julian Rüth | Reviewers: | Dima Pasechnik |
Report Upstream: | N/A | Work issues: | |
Branch: | 76732a4 (Commits) | Commit: | 76732a48e18ca9a286df3821446f3ffe2d3f2727 |
Dependencies: | Stopgaps: |
Description (last modified by )
At least on archlinux
autoreconf: running: automake-1.10 --add-missing --copy Useless use of /d modifier in transliteration operator at /opt/sage/local/var/tmp/sage/build/autotools-20141105.p0/build/automake-1.10/lib/Automake/Wrap.pm line 60. Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /opt/sage/local/var/tmp/sage/build/autotools-20141105.p0/build/automake-1.10/automake line 3823. autoreconf: automake-1.10 failed with exit status: 255 make[4]: *** [Makefile:665: amhello-1.0.tar.gz] Error 1
The branch attached to this ticket proposes to drop this SPKG.
Attachments (1)
Change History (27)
Changed 21 months ago by
comment:1 Changed 21 months ago by
- Description modified (diff)
comment:2 Changed 21 months ago by
- Cc mkoeppe added
comment:3 Changed 21 months ago by
- Priority changed from blocker to critical
comment:4 Changed 21 months ago by
It may be worth checking whether the approach of this package, namely to build ALL versions of the autotools, is still necessary. Perhaps it's better to just replace it by a simple package that builds a set of recent versions. If there are sage packages that really need a specific set of autotools versions, that's something that can be fixed by patching (and sending these patches upstream).
comment:5 Changed 20 months ago by
From the SPKG.txt
file it does not seem that this was to make packages work that need a specific version of autotools. Rather the idea was to use the same version of autotools that was used to create the original configure
and friends when patching something like configure.in
. This keeps the patches small.
I can see why this was done and this is certainly a nice idea but I am not sure it warrants this package in Sage. The configure
file is generated, so shouldn't we just trust a recent version of autotools and try to make our changes to configure.in
small?
Anyway, the autotools SPKG does not build for me. I can not remove the offending versions of automake because the ./spkg-write-makefile
script needs the autotools SPKG to be installed already.
comment:6 Changed 20 months ago by
It appears that Perl has changed how it handles unescaped braces, https://stackoverflow.com/questions/43165604/unescaped-left-brace-regex-error. This used to be deprecated and probably it's an error now. My perl is 5.26.1 (archlinux.)
I'll try to install an old perl and drop the problematic versions of automake.
comment:7 Changed 20 months ago by
With an older perl (5.24.1) I only get a deprecation:
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /home/jule/proj/sage/sage/local/automake-1.10/bin/automake line 3823.
comment:8 Changed 20 months ago by
The issue is fixed in automake since this commit which is in 1.15.1+.
commit 13f00eb4493c217269b76614759e452d8302955e Author: Paul Eggert <eggert@cs.ucla.edu> Date: Thu Mar 31 16:35:29 2016 -0700 automake: port to Perl 5.22 and later Without this change, Perl 5.22 complains "Unescaped left brace in regex is deprecated" and this is planned to become a hard error in Perl 5.26. See: http://search.cpan.org/dist/perl-5.22.0/pod/perldelta.pod#A_literal_%22{%22_should_now_be_escaped_in_a_pattern * bin/automake.in (substitute_ac_subst_variables): Escape left brace.
So that means that everything between 1.10 and 1.15 is affected.
comment:9 Changed 20 months ago by
mkoeppe: What should we do now?
- Drop the affected versions? (that's the easiest I think)
- Just package recent versions as you proposed earlier.
- Package none at all, and just expect SPKG developers to have recent autotools (I think that's better than 2 actually.)
- Cherry-pick the fixing commit into every tag and make this SPKG more complicated than it is already.
- ?
comment:10 Changed 20 months ago by
I've found it somewhat convenient that this makes it easy to install multiple autoconf/automake versions side-by-side, which isn't always as easy to do at the system level. It's rare that I've needed to do this--as you mentioned earlier it's if I've had to patch something in package's configure.ac and generate a new configure while keeping the patch itself comprehensible.
That said, I don't think this is all that important either. As long as the patch made to configure.ac is small I don't think we care about the size of the patch to the configure script itself.
Considering the trouble it's becoming, I'm also in favor of just dropping support for the autotools SPKG. It's not worth the effort to maintain, and its purpose can be fulfilled in other ways.
comment:11 Changed 20 months ago by
- Branch set to u/saraedum/drop_autotools
comment:12 Changed 20 months ago by
- Commit set to ef59eba16ba9f0e1b025c0430abcf6900cd6d049
- Description modified (diff)
New commits:
ef59eba | Drop optional autotools SPKG
|
comment:13 Changed 20 months ago by
- Priority changed from critical to major
Downgrading as many distributions (such as Debian) are not yet affected.
comment:14 Changed 20 months ago by
- Status changed from new to needs_review
- Work issues set to test
How should I test that this does not break anything? Rebuild from scratch?
comment:15 Changed 20 months ago by
the original purpose of this package is to provide some autotool version in situations where there is none, e.g. on OSX.
building autotools from scratch is not very straightforward, e.g. I recall needing once to build a newer m4 to build it, etc etc.
I think it either should be dropped or fixed to work on all platforms.
I guess we might need a vote on sage-devel in order to drop it.
comment:16 Changed 20 months ago by
Is autotools not available with brew on OSX now? Otherwise it should also be available with conda.
comment:17 follow-up: ↓ 18 Changed 20 months ago by
I don't know whether it is available with either of them, what is known is that neither of them work with Sage.
That is, building/running Sage in either of these environments does not work.
Yes, probably one can run Sage's ./bootstrap in either of them, then uninstall them and proceed with building Sage :-)
comment:18 in reply to: ↑ 17 Changed 20 months ago by
Replying to dimpase:
I don't know whether it is available with either of them, what is known is that neither of them work with Sage.
That is, building/running Sage in either of these environments does not work.
I don't have OSX here but why would Sage not build if conda's autotools are on the path? At least at conda-forge's https://github.com/conda-forge/sagelib-feedstock/ we do not do any autools related patching as far as I know.
Yes, probably one can run Sage's ./bootstrap in either of them, then uninstall them and proceed with building Sage :-)
That sounds like it would be a quite annoying workflow. But you would only have to do that when you change configure.ac and such, right?
comment:19 Changed 20 months ago by
- Status changed from needs_review to needs_info
- Work issues changed from test to test, can we drop autotools on OSX?
comment:20 Changed 20 months ago by
Optional packages that are broken on some arcs are to be downgraded to experimental. We can do this, for sure.
comment:21 Changed 20 months ago by
- Commit changed from ef59eba16ba9f0e1b025c0430abcf6900cd6d049 to 76732a48e18ca9a286df3821446f3ffe2d3f2727
comment:22 follow-up: ↓ 24 Changed 20 months ago by
- Status changed from needs_info to needs_review
Ok. Do we need a vote for downgrading this to experimental?
comment:23 Changed 20 months ago by
- Work issues test, can we drop autotools on OSX? deleted
comment:24 in reply to: ↑ 22 Changed 20 months ago by
Replying to saraedum:
Ok. Do we need a vote for downgrading this to experimental?
a package that is broken somehow downgrades itself.
comment:25 Changed 20 months ago by
- Reviewers set to Dima Pasechnik
- Status changed from needs_review to positive_review
comment:26 Changed 19 months ago by
- Branch changed from u/saraedum/drop_autotools to 76732a48e18ca9a286df3821446f3ffe2d3f2727
- Resolution set to fixed
- Status changed from positive_review to closed
Optional packages aren't release blockers