#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 saraedum)

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 vdelecroix 21 months ago.

Download all attachments as: .zip

Change History (27)

Changed 21 months ago by vdelecroix

comment:1 Changed 21 months ago by vdelecroix

  • Description modified (diff)

comment:2 Changed 21 months ago by vdelecroix

  • Cc mkoeppe added

comment:3 Changed 21 months ago by vbraun

  • Priority changed from blocker to critical

Optional packages aren't release blockers

comment:4 Changed 21 months ago by mkoeppe

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 saraedum

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 saraedum

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 saraedum

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 20 months ago by saraedum (previous) (diff)

comment:8 Changed 20 months ago by saraedum

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 saraedum

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 20 months ago by saraedum (previous) (diff)

comment:10 Changed 20 months ago by embray

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 saraedum

  • Branch set to u/saraedum/drop_autotools

comment:12 Changed 20 months ago by saraedum

  • Authors set to Julian Rüth
  • Commit set to ef59eba16ba9f0e1b025c0430abcf6900cd6d049
  • Description modified (diff)

New commits:

ef59ebaDrop optional autotools SPKG

comment:13 Changed 20 months ago by saraedum

  • Priority changed from critical to major

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

comment:14 Changed 20 months ago by saraedum

  • 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 dimpase

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 saraedum

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

comment:17 follow-up: Changed 20 months ago by 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.

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 saraedum

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 saraedum

  • 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 dimpase

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 git

  • Commit changed from ef59eba16ba9f0e1b025c0430abcf6900cd6d049 to 76732a48e18ca9a286df3821446f3ffe2d3f2727

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

a7cf452Revert "Drop optional autotools SPKG"
76732a4Make autotools experimental

comment:22 follow-up: Changed 20 months ago by saraedum

  • 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 saraedum

  • Work issues test, can we drop autotools on OSX? deleted

comment:24 in reply to: ↑ 22 Changed 20 months ago by dimpase

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 dimpase

  • Reviewers set to Dima Pasechnik
  • Status changed from needs_review to positive_review

comment:26 Changed 19 months ago by vbraun

  • Branch changed from u/saraedum/drop_autotools to 76732a48e18ca9a286df3821446f3ffe2d3f2727
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.