Package Details: armadillo 11.2.3-1

Git Clone URL: (read-only, click to copy)
Package Base: armadillo
Description: C++ linear algebra library
Upstream URL:
Licenses: Apache
Submitter: None
Maintainer: valandil
Last Packager: valandil
Votes: 56
Popularity: 0.58
First Submitted: 2009-12-14 16:43 (UTC)
Last Updated: 2022-07-14 01:04 (UTC)

Latest Comments

valandil commented on 2020-05-05 02:07 (UTC)

I wouldn't want to add those to makedepends, mostly because they not only needed for building, but also at runtime.

The other way is add PKGBUILDs for all variants (hdf5+intelmpi,intelmpi,hdf5), but I don't want to support a combinatorial number of packages. I wish the build system had something similar to Spack's variants...

Anyway, the simplest solution is add cleanup up the optdepends, and maybe add a note saying if you want the benefit of the optional dependencies, to install them, then recompile armadillo. Its CMakeLists.txt will pick them up.

Sounds fair?

hottea commented on 2020-05-05 00:16 (UTC) (edited on 2020-05-05 00:51 (UTC) by hottea)

Would you consider add intel-mkl, hdf5 to makedepends? If these pkgs are not installed or listed in makedepends, there is no reason to add them as optdepends since they will not be linked with armadillo. Also, acml-cblas should be removed, since there is no such pkg in official repo or aur. armadillo doesn't seem to depend on cuda.

valandil commented on 2016-05-20 13:15 (UTC)

yaourt -S --nodeps superlu yaourt -S armadillo

ochurlaud commented on 2016-05-19 21:39 (UTC)

I got this error by updating... error: failed to prepare transaction (could not satisfy dependencies) :: armadillo: installing superlu (5.2.0-1) breaks dependency 'superlu=4.3' ==> WARNING: Your packages are saved in /tmp/yaourt-tmp-olivier

valandil commented on 2016-05-19 15:00 (UTC)

This is only a temporary situation. When 7.100.0 goes out of test, I will go back to using the stable version. I am doing it this way because otherwise I would have to create a superlu4 package just for armadillo 6.*.*.

ochurlaud commented on 2016-05-18 22:25 (UTC)

Using the test version here is maybe not a good idea: there is no stable package on archlinux... Could you reconsider?

valandil commented on 2016-05-17 13:50 (UTC)

I've updated this to the latest test version to make sure that SuperLU and armadillo play nice. If you encounter any issue, please contact me.

berquist commented on 2015-11-11 00:23 (UTC)

Oops, forgot to update the checksum.

valandil commented on 2015-09-25 22:12 (UTC)

Unless people ask for version 6.000, I think I'm gonna hold off until they remove the test flag upstream.

valandil commented on 2015-09-15 17:37 (UTC)

I'm currently on vacation with a limited access to the Internet. Will update in two weeks.

commented on 2015-09-14 09:45 (UTC)

new version is out!

valandil commented on 2015-04-13 21:14 (UTC)

This new version of armadillo uses 64-bit integers by default is C++11 is available. Be careful. Please report any issues.

valandil commented on 2015-03-20 18:16 (UTC)

Hey gilesc, I cannot seem to replicate this issue. Could you post a more detailed error report? Thanks.

Kknd commented on 2015-03-20 17:40 (UTC)

Hi, I'm not using armadillo anymore, so I'm releasing it to someone who will be capable of keeping it updated.

gilesc commented on 2015-02-22 18:20 (UTC)

With valandil's changes, I am getting the same "wasn't compiled for 64 bit" again. According to this link [1], which is admittedly old, it says ARMA_64BIT_WORD it must be changed in the header file and cannot be set in CMake directly. I am not sure if this is the problem but in any case if I add back xan's code it works again. [1]

Kknd commented on 2015-01-16 17:03 (UTC)

The problem seems to be fixed now. Thanks!

valandil commented on 2015-01-08 20:28 (UTC)

Something like that might be cleaner: build() { ARMA64BITWORD="" if [ "$CARCH" == "x86_64" ]; then ARMA64BITWORD="ARMA_64BIT_WORD" ARMA64LIBDIR="-DINSTALL_LIB_DIR:PATH=/usr/lib" fi cd "${srcdir}/$pkgname-$pkgver" cmake $ARMA64BITWORD $ARMA64LIBDIR -DCMAKE_INSTALL_PREFIX:PATH=/usr . make } as the CMakeLists.txt of armadillo allows the specification of the lib directory.

Rufflewind commented on 2015-01-07 21:10 (UTC)

Pacman is failing to install the package because it contains /usr/lib64 as a directory, which on Arch Linux is just a symlink to /usr/lib. To work around this, I added the following to the `package` function, immediately after the `make` line: [ "$CARCH" = x86_64 ] && mv "${pkgdir}/usr/lib64" "${pkgdir}/usr/lib"

Kknd commented on 2015-01-04 01:21 (UTC)

Hi, I've added the prepare() that xan provided, and it seems to be working here. thanks.

xantares commented on 2014-12-28 13:23 (UTC)

hi, you have to replace it manually: prepare() { cd "${srcdir}/armadillo-$pkgver" if [ "$CARCH" == "x86_64" ]; then sed -i "s|// #define ARMA_64BIT_WORD|#define ARMA_64BIT_WORD|g" include/armadillo_bits/config.hpp.cmake fi } xan.

gilesc commented on 2014-12-19 22:15 (UTC)

I don't think the changes by Carlinix actually enable 64-bit mode for Armadillo. When I use this PKGBUILD (on a 64-bit system), and then compile a downstream package, "mlpack", it complains that armadillo wasn't compiled for 64 bits. It looks like it actually has to be enabled in either include/armadillo_bits/config.hpp or {..}/config.hpp.cmake . Not sure which.

Kknd commented on 2014-11-11 18:32 (UTC)

Done, thanks!

Carlinix commented on 2014-11-11 15:14 (UTC)

I think that for a 64bits environment it is good enable the option ARMA_64BIT_WORD like this: build() { ARMA64BITWORD="" if [ "$CARCH" == "x86_64" ]; then ARMA64BITWORD="ARMA_64BIT_WORD" fi cd "${srcdir}/$pkgname-$pkgver" cmake $ARMA64BITWORD -DCMAKE_INSTALL_PREFIX:PATH=/usr . make }

Kknd commented on 2014-09-12 17:11 (UTC)

Thanks for the report. I plan to wait for a while to see any upstream changes.

oniram commented on 2014-09-12 16:33 (UTC)

Update to 4.400.2 breaks HDF5 support. From their changelog: 2014-09-09 Version 4.400.2 * disabled automatic detection of HDF5 to prevent compilation problems They commented lines 227 to 234 in file CMakeLists.txt. I've solved the problem here by uncommenting those lines. I personally need support for HDF5. Don't know what would be the correct way to fix this for everybody in the package.

Kknd commented on 2014-06-17 18:35 (UTC)


xantares commented on 2014-06-17 18:16 (UTC)

you need to pass -DINSTALL_LIB_DIR=lib for it not to install into /lib64

Kknd commented on 2014-06-03 11:20 (UTC)

Some dependencies were changed: boost is required only when building, and hdf5 was added as a new dependency.

ivan-kryukov commented on 2014-06-03 04:00 (UTC)

Here is an updated PKGBUILD (4.300.8):

jellysheep commented on 2013-06-05 19:28 (UTC)

Hi, according to their project page, they release version 3.900.0.

big_gie commented on 2013-03-04 14:11 (UTC)

Version 3.800.0 is out and is MPL 2.0 licensed now.

Kknd commented on 2013-01-15 23:30 (UTC)

Hi, As far as I know, Armadillo compiles without blas/lapack, but it is kinda useless, supporting only basic operations like matrix multiplication. Here, I've just did: $ pacman -S lapack Linking with -larmadillo links with lapack and blas automatically. In fact, armadillo code resides almost all in headers. Linking with armadillo just links links with lapack and blas.

onefire commented on 2013-01-15 22:04 (UTC)

I could only use it after applying a patch to disable ARMA_USE_WRAPPER: sed 's/#define ARMA_USE_WRAPPER/\/\/#define ARMA_USE_WRAPPER/g' /usr/include/armadillo_bits/config.hpp > tmp && mv tmp /usr/include/armadillo_bits/ My friend also had trouble installing it on his Mac, but the above command worked for him too. After this, I can compile with something like: g++ myprog.cpp -o myprog -llapack -lblas Armadillo's website claims that blas and lapack are not strictly necessary, so I tried to install it on a minimal Arch install on Virtual Box. Then I could compile programs with just: g++ myprog.cpp -o myprog -larmadillo So my question is: What is the correct way to install the library with blas and everything?

Kknd commented on 2012-12-17 22:22 (UTC)

I do not know what this means, since it does find boost latter, as evidenced by the latter output: ... -- Boost version: 1.50.0 -- Boost_MAJOR_VERSION = 1 -- Boost_MINOR_VERSION = 50 -- Boost_INCLUDE_DIR = /usr/include ...

myles commented on 2012-12-17 21:43 (UTC)

Thanks for updating. I get this: -- Configuring Armadillo 3.6.1 -- Could NOT find Boost

commented on 2012-07-28 00:15 (UTC)

3.2.4 is out:

toffyrn commented on 2012-06-01 18:23 (UTC)

There is currently a issue with the newest armadillo versions (3.2.0/3.2.1) and gcc >4.7.0, see: Just to keep you informed.

PedsXing commented on 2012-02-22 16:21 (UTC)

2.4.3 is out: