Opened 5 years ago

Closed 5 years ago

#24903 closed defect (fixed)

optional package autotools fail to build

Reported by: Vincent Delecroix Owned by:
Priority: major Milestone: sage-8.2
Component: packages: optional Keywords:
Cc: Matthias Köppe Merged in:
Authors: Julian Rüth Reviewers: Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: 76732a4 (Commits, GitHub, GitLab) Commit: 76732a48e18ca9a286df3821446f3ffe2d3f2727
Dependencies: Stopgaps:

Status badges

Description (last modified by Julian Rüth)

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)

autotools-20141105.p0.log (331.5 KB) - added by Vincent Delecroix 5 years ago.

Download all attachments as: .zip

Change History (27)

Changed 5 years ago by Vincent Delecroix

Attachment: autotools-20141105.p0.log added

comment:1 Changed 5 years ago by Vincent Delecroix

Description: modified (diff)

comment:2 Changed 5 years ago by Vincent Delecroix

Cc: Matthias Köppe added

comment:3 Changed 5 years ago by Volker Braun

Priority: blockercritical

Optional packages aren't release blockers

comment:4 Changed 5 years ago by Matthias Köppe

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 5 years ago by Julian Rüth

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 5 years ago by Julian Rüth

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 5 years ago by Julian Rüth

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.
Last edited 5 years ago by Julian Rüth (previous) (diff)

comment:8 Changed 5 years ago by Julian Rüth

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 5 years ago by Julian Rüth

mkoeppe: What should we do now?

  1. Drop the affected versions? (that's the easiest I think)
  2. Just package recent versions as you proposed earlier.
  3. Package none at all, and just expect SPKG developers to have recent autotools (I think that's better than 2 actually.)
  4. Cherry-pick the fixing commit into every tag and make this SPKG more complicated than it is already.
  5. ?
Last edited 5 years ago by Julian Rüth (previous) (diff)

comment:10 Changed 5 years ago by Erik Bray

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 5 years ago by Julian Rüth

Branch: u/saraedum/drop_autotools

comment:12 Changed 5 years ago by Julian Rüth

Authors: Julian Rüth
Commit: ef59eba16ba9f0e1b025c0430abcf6900cd6d049
Description: modified (diff)

New commits:

ef59ebaDrop optional autotools SPKG

comment:13 Changed 5 years ago by Julian Rüth

Priority: criticalmajor

Downgrading as many distributions (such as Debian) are not yet affected.

comment:14 Changed 5 years ago by Julian Rüth

Status: newneeds_review
Work issues: test

How should I test that this does not break anything? Rebuild from scratch?

comment:15 Changed 5 years ago by Dima Pasechnik

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 5 years ago by Julian Rüth

Is autotools not available with brew on OSX now? Otherwise it should also be available with conda.

comment:17 Changed 5 years ago by Dima Pasechnik

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 5 years ago by Julian Rüth

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 5 years ago by Julian Rüth

Status: needs_reviewneeds_info
Work issues: testtest, can we drop autotools on OSX?

comment:20 Changed 5 years ago by Dima Pasechnik

Optional packages that are broken on some arcs are to be downgraded to experimental. We can do this, for sure.

comment:21 Changed 5 years ago by git

Commit: ef59eba16ba9f0e1b025c0430abcf6900cd6d04976732a48e18ca9a286df3821446f3ffe2d3f2727

Branch pushed to git repo; I updated commit sha1. New commits:

a7cf452Revert "Drop optional autotools SPKG"
76732a4Make autotools experimental

comment:22 Changed 5 years ago by Julian Rüth

Status: needs_infoneeds_review

Ok. Do we need a vote for downgrading this to experimental?

comment:23 Changed 5 years ago by Julian Rüth

Work issues: test, can we drop autotools on OSX?

comment:24 in reply to:  22 Changed 5 years ago by Dima Pasechnik

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 5 years ago by Dima Pasechnik

Reviewers: Dima Pasechnik
Status: needs_reviewpositive_review

comment:26 Changed 5 years ago by Volker Braun

Branch: u/saraedum/drop_autotools76732a48e18ca9a286df3821446f3ffe2d3f2727
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.