Package Details: macaulay2 19030.995c6fd8c-1

Git Clone URL: (read-only, click to copy)
Package Base: macaulay2
Description: Software system for algebraic geometry and commutative algebra
Upstream URL:
Licenses: GPL
Submitter: remyoudompheng
Maintainer: ConnorBehan
Last Packager: ConnorBehan
Votes: 5
Popularity: 0.000000
First Submitted: 2009-04-09 17:09 (UTC)
Last Updated: 2021-05-21 16:12 (UTC)

Latest Comments

DanGrayson commented on 2022-01-15 15:50 (UTC)

Ah, right -- good catch. Mike Stillman is working on getting it compatible with both old tbb and new tbb.

8d1h commented on 2022-01-12 21:16 (UTC)

I was also unable to build with the same error "tbb/tbb_stddef.h: No such file or directory". Finally I figured out that it's possibly because M2 is not yet compatible with tbb 2021. So I downgraded the tbb package (to 2020.3-1), and it worked.

DanGrayson commented on 2022-01-09 17:29 (UTC)

Can you locate the file tbb/tbb_stddef.h ? If it's not in /usr, that could explain it. To see the full command line when trying to compile version.dd, add "VERBOSE=1" to the "make" command line. Then you can see what other "-I" arguments there are.

krmath commented on 2022-01-08 23:16 (UTC)

Having trouble building. On the first attempt, I got the following:

configure: error: tbb include file (tbb.h) not found

After installing tbb from the extra repo with pacman, I got further, but the build terminated with

version.dd:66:15: fatal error: tbb/tbb_stddef.h: No such file or directory

Do I need an additional package? I can't find any info in the archwiki or a wider web search regarding tbb or such errors, so I'm at a loss when it comes to figuring out what I need here.

DanGrayson commented on 2021-07-22 12:29 (UTC)

Re: "Is there any reason for having singular-factory as a dependency and not singular?"

Presumably both provide the factory library and M2 can find it in both cases, so it shouldn't matter from that point of view.

Ideally singular would have been packaged so it gets factory from the package singular-factory, so there would be no conflict. That would be good to change, because singular-factory is lighter weight, and it doesn't make sense for singular to be a dependency of macaulay2.

feynhat commented on 2021-07-22 08:10 (UTC)

singular-factory clashes with singular. If I have singular already installed and I remove singular-factory as a dependency from M2's PKGBUILD, then M2 builds just fine.

Is there any reason for having singular-factory as a dependency and not singular?

Dylan14 commented on 2021-07-18 18:49 (UTC)

It should be noted in the PKGBUILD that this conflicts with the givaro package in the repository.

Dylan14 commented on 2021-05-21 13:34 (UTC) (edited on 2021-05-21 13:35 (UTC) by Dylan14)

gcc10 needs to be added as a make dependency, as one of the dependencies that Macaulay downloads when it is building, mathicgb, fails to build under gcc 11.1 (see the following issue: There is a pending pull request to fix this:

DanGrayson commented on 2021-04-02 18:50 (UTC)

Re: "I've heard that one dependency is no longer needed"

They seem to be referring to "frobby", but Macaulay2 still requires it.

micwoj92 commented on 2021-04-02 18:29 (UTC)

Hello, could you either switch to use tags or reupload this as -git package? Also I've heard that one dependency is no longer needed

8d1h commented on 2021-03-07 15:42 (UTC)

That's great, thanks a lot! Glad I could help.

DanGrayson commented on 2021-03-07 14:04 (UTC)

Oh, right. I've just checked, and our configuration files do not use those two variables, so it's safe for you to remove those lines. I've also checked that autoconf 2.69, which we use, sets them, but autoconf 2.71, which you use, does not. So I've removed those lines in our development branch (see below) and will upgrade the configure script to work well with 2.71 (currently it gets lots of warnings).

commit ffd0589f33e9b95b306720597ba831fcd93be679 (HEAD -> development, upstream/development) Author: Daniel R. Grayson Date: Sun Mar 7 07:50:21 2021 -0600

remove obsolete configure variables from include/

..., namely CXXCPP and EGREP.  They were produced by autoconf 2.69 but not by autoconf 2.71.

Thanks for drawing my attention to this.

8d1h commented on 2021-03-07 01:28 (UTC)

From "include/configuration". I first ran configure in the "M2" directory, removed the lines, and then ran make again and it worked. I guess that this is generated from the template file "include/" and somehow these two didn't get replaced?

DanGrayson commented on 2021-03-06 18:48 (UTC)

Which file did you remove those lines from?

8d1h commented on 2021-03-06 17:50 (UTC)

I've been running into the same error too. Had to manually remove the two lines with CXXCPP=@CXXCPP@ and EGREP=@EGREP@, and the build finished successfully without any other errors.

DanGrayson commented on 2021-02-15 23:51 (UTC)

Make sure you've installed the appropriate tbb packages (threaded building blocks).

onecan commented on 2021-02-15 23:25 (UTC) (edited on 2021-02-15 23:26 (UTC) by onecan)

Thanks for the speedy response.

I was using autoconf 2.71-1. Going to src/M2/M2 and running "make get-autoconf" returned the error "No rule to make target `get-autoconf'", but downgrading my autoconf to 2.69-7 avoided the "underfined configure variables" error below.

I now get a bunch of new errors:

fflas_fsyrk_strassen.inl:404:13: error: ‘class Givaro::IntSqrtModDom<>’ has no member named ‘sumofsquaresmodprime’
  404 |         ISM.sumofsquaresmodprime (a, b, -1, F.characteristic());
      |             ^~~~~~~~~~~~~~~~~~~~
In file included from VectorArithmetic.cpp:1:
VectorArithmetic.hpp: At global scope:
VectorArithmetic.hpp:108:40: error: ‘tbb’ has not been declared
  108 |                                        tbb::queuing_mutex& lock) const = 0;
      |                                        ^~~
VectorArithmetic.hpp:108:58: error: expected ‘,’ or ‘...’ before ‘&’ token
  108 |                                        tbb::queuing_mutex& lock) const = 0;
      |                                                          ^
VectorArithmetic.hpp:116:40: error: ‘tbb’ has not been declared
  116 |                                        tbb::null_mutex& lock) const = 0;
      |                                        ^~~
VectorArithmetic.hpp:116:55: error: expected ‘,’ or ‘...’ before ‘&’ token
  116 |                                        tbb::null_mutex& lock) const = 0;
      |                                                       ^
VectorArithmetic.hpp:110:16: error: ‘virtual void AbstractVectorArithmetic::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’ cannot be overloaded with ‘virtual void AbstractVectorArithmetic::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’
  110 |   virtual void safeDenseRowToSparseRow(DenseCoeffVector& dense,
      |                ^~~~~~~~~~~~~~~~~~~~~~~
VectorArithmetic.hpp:102:16: note: previous declaration ‘virtual void AbstractVectorArithmetic::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’
  102 |   virtual void safeDenseRowToSparseRow(DenseCoeffVector& dense,
      |                ^~~~~~~~~~~~~~~~~~~~~~~
VectorArithmetic.cpp:186:32: error: ‘tbb’ has not been declared
  186 |                                tbb::queuing_mutex& lock) const override
      |                                ^~~
VectorArithmetic.cpp:186:50: error: expected ‘,’ or ‘...’ before ‘&’ token
  186 |                                tbb::queuing_mutex& lock) const override
      |                                                  ^
VectorArithmetic.cpp:203:32: error: ‘tbb’ has not been declared
  203 |                                tbb::null_mutex& noLock) const override
      |                                ^~~
VectorArithmetic.cpp:203:47: error: expected ‘,’ or ‘...’ before ‘&’ token
  203 |                                tbb::null_mutex& noLock) const override
      |                                               ^
VectorArithmetic.cpp:197:8: error: ‘void ConcreteVectorArithmetic<T>::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’ cannot be overloaded with ‘void ConcreteVectorArithmetic<T>::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’
  197 |   void safeDenseRowToSparseRow(DenseCoeffVector& dense,
      |        ^~~~~~~~~~~~~~~~~~~~~~~
VectorArithmetic.cpp:180:8: note: previous declaration ‘void ConcreteVectorArithmetic<T>::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’
  180 |   void safeDenseRowToSparseRow(DenseCoeffVector& dense,
      |        ^~~~~~~~~~~~~~~~~~~~~~~
VectorArithmetic.cpp: In member function ‘void ConcreteVectorArithmetic<T>::denseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&) const’:
VectorArithmetic.cpp:170:5: error: ‘tbb’ has not been declared
  170 |     tbb::null_mutex noLock;
      |     ^~~
VectorArithmetic.cpp:171:32: error: ‘tbb’ was not declared in this scope
  171 |     generalDenseRowToSparseRow<tbb::null_mutex>(dense,
      |                                ^~~
VectorArithmetic.cpp:171:5: error: parse error in template argument list
  171 |     generalDenseRowToSparseRow<tbb::null_mutex>(dense,
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VectorArithmetic.cpp:177:49: error: ‘noLock’ was not declared in this scope
  177 |                                                 noLock);
      |                                                 ^~~~~~
VectorArithmetic.cpp: In member function ‘void ConcreteVectorArithmetic<T>::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’:
VectorArithmetic.cpp:188:32: error: ‘tbb’ was not declared in this scope
  188 |     generalDenseRowToSparseRow<tbb::queuing_mutex>(dense,
      |                                ^~~
VectorArithmetic.cpp:188:5: error: parse error in template argument list
  188 |     generalDenseRowToSparseRow<tbb::queuing_mutex>(dense,
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VectorArithmetic.cpp:194:52: error: ‘lock’ was not declared in this scope; did you mean ‘lockf’?
  194 |                                                    lock);
      |                                                    ^~~~
      |                                                    lockf
VectorArithmetic.cpp: In member function ‘void ConcreteVectorArithmetic<T>::safeDenseRowToSparseRow(DenseCoeffVector&, CoeffVector&, Range<int>&, int, int, MemoryBlock&, int) const’:
VectorArithmetic.cpp:205:32: error: ‘tbb’ was not declared in this scope
  205 |     generalDenseRowToSparseRow<tbb::null_mutex>(dense,
      |                                ^~~
VectorArithmetic.cpp:205:5: error: parse error in template argument list
  205 |     generalDenseRowToSparseRow<tbb::null_mutex>(dense,
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VectorArithmetic.cpp:211:49: error: ‘noLock’ was not declared in this scope
  211 |                                                 noLock);
      |                                                 ^~~~~~
make[2]: *** [Makefile.common:33: VectorArithmetic.o] Error 1

DanGrayson commented on 2021-02-15 22:30 (UTC)

... and then run "make" in the same directory to remake "configure", after deleting "configure", if necessary.

DanGrayson commented on 2021-02-15 22:29 (UTC)

That's strange, it's worked for us. What version of autoconf do you have? You can run "make get-autoconf" in the source directory "M2" to get and use version 2.69.

onecan commented on 2021-02-15 22:20 (UTC)

Build fails with the error:

: "checking for strings that look like undefined configure variables in all *.in files..."
make: *** [GNUmakefile:278: check-for-undefined-configure-variables] Error 1

DanGrayson commented on 2021-01-05 17:03 (UTC)

The tar file can also be obtained from

, according to Hans Schoenemann.

DanGrayson commented on 2021-01-05 02:24 (UTC)

I've sent a message to someone at Singular about the expired certificate. So it might come back to life.

smallmouse commented on 2021-01-04 21:55 (UTC)

the certificate for "" is expired meaning singular-factory can't be installed but I was able to install this anyway by installing "singular" instead and removing the dependency

Dylan14 commented on 2020-10-21 21:04 (UTC)

Working pkgbuild for macaulay2 which circumvents the issue I had:

DanGrayson commented on 2020-10-21 14:16 (UTC)

Since the directory editors/emacs is a submodule, perhaps it hasn't been populated yet. As part of building, you should be running "make" in the "M2" directory of the source tree -- that will create the configure script and populate that submodule. Is it being done? Or maybe it's being done with a target different from 'all' ?

There is no difference between 8b41c61 and 995c6fd.

Dylan14 commented on 2020-10-21 02:39 (UTC) (edited on 2020-10-21 04:19 (UTC) by Dylan14)

@ConnorBehan haven't tried it with a old commit yet, will try it now...

With the commit previous (8b41c61) the build is successful. With the current build (995c6fd) it fails. Will note it as an issue on the upstream github.

ConnorBehan commented on 2020-10-21 02:34 (UTC)

Are you saying this happens with the latest commit because it used to work? If you know a good and bad commit, that should be reported upstream.

Dylan14 commented on 2020-10-21 01:30 (UTC)

With the latest git commit of Macaulay2 there is an error when it gets to building TAGS:

make[2]: *** No rule to make target '../editors/emacs/make-M2-emacs-help.m2', needed by 'TAGS'. Stop.

There doesn't appear to be an option in the makefile or the configure script to disable making it to allow compilation to succeed. This occurs regardless if the package is built manually with makepkg or if an AUR helper is used.

DonkoXI commented on 2020-09-01 06:58 (UTC)


It seems the PKGBUILD needs a few modifications.

The packages eigen, boost, and cblas need to be added to the depends list. The build fails without them. Both eigen and boost are specified in the official INSTALL documentation under Arch Linux. While lapack should provide cblas, I consistently get an error when cblas isn't listed explicitly as a dependency when building in a clean chroot.

Also, Macaulay2/packages/Macaulay2Doc/test/ does not exist in the source code anymore, and so line 35 of the PKGBUILD causes a build error (there is a file of the same name now located in Macaulay2/tests, but I am not familiar enough with the project source code to speak to their relationship).

DanGrayson commented on 2020-07-13 09:49 (UTC)

Good. It shouldn't take any special flags. The way I always build is by running "make" in M2/BUILD/dan, so you can see what that would give to "configure" with "make -n configure" there.

We're on a 6 month release schedule, May 15 and November 15. This time we're a bit late. So that would be a good time for the Arch distribution to get updated.

If you give me an email address, I could add it to my private M2 mailing list, and you would get notified. There might be a few other notifications about conferences and workshops, but those are infrequent. We also announce releases at!forum/macaulay2

ConnorBehan commented on 2020-07-13 00:15 (UTC) (edited on 2020-07-13 00:15 (UTC) by ConnorBehan)

Hi Dan,

Thanks for all the work. That sounds like it will make building easier. I don't use M2 very much these days but the package should of course be updated whenever the changes are significant. So I will start looking into it next week and any suggestions about what flags to use would be most welcome.

DanGrayson commented on 2020-07-11 21:49 (UTC)

Dear Connor,

Thank you for putting Macaulay2 into Arch.

I've been preparing our version 1.16 release and will probably announce it in a day or two. Today I built it successfully under Arch with just a few changes. Since version 1.15, we have stopped insisting on using our own patched version of mpir, and can link either with mpir or gmp, as desired, so there will a lot less bundling required.

Perhaps we can coordinate efforts in bringing the next release out.

pbanks commented on 2019-06-05 13:21 (UTC)

When compiling, I got the following error:

/usr/bin/ld: _ZN3NTL8GF2EInfoE: TLS reference in /usr/local/lib/ mismatches non-TLS definition in /home/peter/.cache/aurman/macaulay2/src/M2/M2/usr-host/lib/libntl.a(GF2E.o) section .bss
/usr/bin/ld: /home/peter/.cache/aurman/macaulay2/src/M2/M2/usr-host/lib/libntl.a: error adding symbols: bad value
collect2: error: ld returned 1 exit status

I fixed this by removing the libraries libntl.a and libfactory.a from the usr-host directory and linking against the system copy of libntl. This then caused an issue with the version of provided by singular-factory. As a workaround, I added --enable-streamio to the arguments passed to configure in the singular-factory PKGBUILD, then rebuilt both packages.

onecan commented on 2019-05-20 00:11 (UTC) (edited on 2019-05-20 00:12 (UTC) by onecan)

I think that yasm is needed as a build dependency and cblas is needed as a dependency. Also, when one tries to install the fully built package with pacman -U, it seems to be trying to install a version of fflas-ffpack in the build directory. Thank your work maintaining this package.

pablo1 commented on 2019-05-07 16:06 (UTC)

Please add readline7 as dependency, it fails to build without it.

petRUShka commented on 2019-02-24 09:31 (UTC) (edited on 2019-02-24 09:31 (UTC) by petRUShka)

Is it necessary to have singular-factory as dependency?

Because singular from community and singular-factory are in conflict. It seems like factory is included in singular package.

But sagemath depends on singular so it in current dependency relationship it is impossible to have sagemath (or other package dependent on singular) and macaulay2 simultaneously.


singular-factory: /usr/share/factory/gftables/729 exists in filesystem (owned by singular)
singular-factory: /usr/share/factory/gftables/7921 exists in filesystem (owned by singular)
singular-factory: /usr/share/factory/gftables/8 exists in filesystem (owned by singular)
singular-factory: /usr/share/factory/gftables/81 exists in filesystem (owned by singular)

blegat commented on 2018-12-08 11:54 (UTC)

I have tried the package and it fails with "openblas_set_num_threads not declared in this scope". This is discussed in!searchin/macaulay2/openblas_set_num_threads%7Csort:date/macaulay2/TZRdOEyh1Z0/HN4WAbBkBQAJ where they advise not to use the system openblas library and let macaulay2 compile its own. Should this AUR package be updated to do that ? Probably the ArchLinux openblas package was updated and it breaks this AUR package.

kmarius commented on 2018-12-03 16:01 (UTC) (edited on 2018-12-03 16:01 (UTC) by kmarius)

The CFLAGS issue should be fixed in

Nevertheless I am unable to compile it using the shared libraries. Building completely from source works, with


./configure --enable-download --prefix=/usr

make -j1

This took over an hour and a half to compile.

onecan commented on 2018-11-26 23:46 (UTC)

Did anyone ever find a way around the issue that Sleris describes below?

ConnorBehan commented on 2017-11-12 05:46 (UTC)

That's clearly a CFLAGS quoting error. I'm not sure which file it's in, but you can probably bypass this by going back to the default.

Sleris commented on 2017-11-09 16:16 (UTC)

I confirm jneem comment, the package require yasm to build. But even with it, the compilation fail while building cohomcalg. I am getting a strange error that I am not even able to understand looking at the various make files: make: Entering directory '/var/tmp/pkgbuild-0/macaulay2/src/M2/M2/libraries/cohomcalg/build' + : + touch .configured-031b === making .compiled-031b in cohomcalg + set +x make: Entering directory '/var/tmp/pkgbuild-0/macaulay2/src/M2/M2/libraries/cohomcalg/build' + make -j1 prefix=/var/tmp/pkgbuild-0/macaulay2/src/M2/M2/usr-host CC=gcc CXX=g++ LD=g++ CFLAGS=-std=gnu11 -march=x86-64 -mtune=generic -pipe -fstack-protector-strong -fno-plt -g3 -O2 make : option invalide -- 'a' make : option invalide -- 'c' make : option invalide -- '=' make : option invalide -- 'x' make : option invalide -- '8' make : option invalide -- '6' make : option invalide -- '-' make : option invalide -- '6' make : option invalide -- '4' make : option invalide -- 'u' make : option invalide -- '=' make : option invalide -- 'g' make : option invalide -- 'c' make : option invalide -- 'g' make : option invalide -- '3' Utilisation : make [options] [cible] ... [...] make[2]: *** [../Makefile.library:155: .compiled-031b] Error 2 make[2] : on quitte le répertoire « /var/tmp/pkgbuild-0/macaulay2/src/M2/M2/libraries/cohomcalg » make[1]: *** [Makefile:7: all-in-cohomcalg] Error 2 make[1] : on quitte le répertoire « /var/tmp/pkgbuild-0/macaulay2/src/M2/M2/libraries » make: *** [GNUmakefile:191: all-in-libraries] Error 2 make : on quitte le répertoire « /var/tmp/pkgbuild-0/macaulay2/src/M2/M2 » ==> ERREUR : Une erreur s’est produite dans build(). Abandon... ==> ERROR: the build failed -> Status failed (1): macaulay2

jneem commented on 2017-07-11 20:51 (UTC)

There's a missing dependency on yasm, without which macaulay2 fails to build.

mcboro commented on 2017-03-21 12:55 (UTC)

I've been trying to compile Macaulay2 from git. The command I used was CC=gcc-5 CXX=g++-5 ./configure --enable-download --enable-build-libraries="pari flint ntl gc givaro factory fflas-ffpack" There were two problems: first, mpir bundled with Macaulay2 fails to compile. The AUR mpir package works, maybe there is a nice way of disabling mpir compilation, but I just changed the variable BUILD_mpir=yes in to no. Then the file 'Macaulay2/bin/timestamp.c didn't compile, because of no-linking to cblas. A dirty workaround was to edit Macaulay2/bin/Makefile and change -lblas -lblas to -lblas -lcblas. During the test phase there is an error "error: file not found on path: "MultipolynomialResultants.m2", but the ./M2 command seems to work.

thelongdivider commented on 2017-01-16 18:25 (UTC)

For anyone still having problems compiling this from source, Daniel recommended to me that instead one can use the common files, for which you will need 2: Extract them in the same directory. You may also need to link libreadline as follows: sudo ln -s /usr/lib/ /usr/lib/ Run the program from Macaulay2-1.9.2/bin/M2. Then one can setupEmacs() to avoid having to reach out to the folder every time they want to use M2.

johnl commented on 2016-12-23 20:35 (UTC)

Current build fails, I think because the version of givaro provided by Arch is too recent to work with M2. I am hesitant to downgrade it, since the current version is a dependency for sage.

commented on 2015-10-18 18:56 (UTC)

Current macaulay2 version (12992.639ac3c-1) fails during compilation. An error inside build() function is returned. I tried on different machines, but the result was the same. Here the details of the error:

johnl commented on 2015-04-27 14:21 (UTC)

I had a hard time building this a few months ago due to various out-of-date dependencies, and ended up giving up. I just tried again with the current versions and encountered no trouble at all. The one tweak that's needed was the python 2 trick mentioned by thelongdivider. Thanks very much to the maintainers!

thelongdivider commented on 2014-12-10 06:12 (UTC)

I have managed to build from github M2 1.7, with a little modification (Python 2 script from the python arch webpage, manually adding the static library libgfortran.a to /usr/lib, etc). Here is the package: Just cd in M2/M2, and run "make install", and the package will install to /usr/local (read M2/M2/INSTALL to install to a different directory, etc)

czsan commented on 2014-12-04 16:48 (UTC)

It depends from singular-factory package, but that is flagged out-of-date (2011-03-19).

day commented on 2014-08-24 14:31 (UTC)

It compiled fine after running that though "make check" still failed. But that's not a big issue. Thanks very much!

ConnorBehan commented on 2014-08-23 21:08 (UTC)

That's why I ran sed -i -e '/lgfortran/d' on Is there still a problem with this?

day commented on 2014-08-23 20:14 (UTC)

There's a little problem with the gcc-fortran compiler. The libgfortran library in the default arch repository doesn't contain the static library 'libgfortran.a' though there exists the dynamical one ''. However, compiling M2 needs this static lib file otherwise there'll be a '-lgfortran' error stopping the compiling process. I figure a way to avoid this error by downloading and extracting the debian libgfortran-dev package to get 'libfortran.a' file so I don't need to compile the whole gcc statically myself. After that I successfully compiled M2.

ConnorBehan commented on 2014-08-06 20:02 (UTC)

It seems like there is a conflict with the newest pari and a couple other upstream bugs.

ConnorBehan commented on 2011-02-25 05:28 (UTC)

You should also use --libexecdir='${prefix}'/lib/Macaulay2

ConnorBehan commented on 2011-01-23 18:10 (UTC)

Updating this to the 1.4 branch required two sed commands for me. After the configure script, run: sed -i -r 's/^\tobjdump(.*)/#\tobjdump\1/g' Macaulay2/bin/Makefile sed -i -r 's/^\techo(.*)/#\techo\1/g' Macaulay2/bin/Makefile i.e. you have to comment out two lines. Then it will build but a run-time dependency will be gc-7.2alpha4. gc-7.1 won't work anymore.

remyoudompheng commented on 2010-06-21 08:32 (UTC)

Add missing makedepends: subversion, unzip.

remyoudompheng commented on 2010-06-02 10:59 (UTC)

10971-3: don't build gfan and use the one provided by the AUR package.

remyoudompheng commented on 2010-04-23 07:01 (UTC)

10971-2: add missing mpir dependency