[MBDyn-users] compiling on Arch Linux

Pierangelo Masarati pierangelo.masarati at polimi.it
Mon Sep 22 16:07:31 CEST 2014

On 09/21/2014 12:20 PM, David Verelst wrote:
> Dear All,

Hello.  Thank you for your interest in the project.

> I am trying to get started with MBDyn by creating an Arch Linux PKGBUILD
> for the Arch User Repositories (AUR).

We do not support nor endorse any specific distribution; however, we 
would happily consider fixes and improvements of general usefulness.  As 
a general rule, a modification that does not break (known) standards and 
does not prevent building on systems we use or we are able to test with 
is welcome.  Changes intended to work around bugs in distributions or 
third-party software are usually not welcomed.  In those cases, it is 
preferred to have a patch (i.e. something that is specific to the 
distribution and not part of the project's code) that is applied prior 
to packaging for the specific distribution.  I'm willing to help in the 
preparation of such patches, based on time availability and knowledge of 
the specific problem.  I hope you find this attitude reasonable.

> I would like to share some issues I am having during the build process.
> * it seems the configure file has one hard coded python statement left
> instead of using the %PYTHON variable. I've included a patch that solved
> the issue for me.

Sure.  This patch sounds correct, I'll apply it.

> * I am not sure why, but in configure.in <http://configure.in> the numpy
> checking code block is repeated again. Also here there is a literal
> reference to "python -c". But it doesn't seem to be ever calling this
> block during the build process. Or at least, the build process doesn't
> complain about a failed NumPy check. On Arch Linux this test has to fail
> since python refers to python 3 for which print now is a function (print
> is used as a statement and not a function in the test).

So far, I only built with python 2.X; I don't exactly recall why the 
check was duplicated.  I'd be happy to streamline it, provided it works 
with out of the box installations of current versions of python.

> * umfpack (which is packaged in the suitesparse package) is installed,
> and configure passes all but the last test. The last test involves
> "checking for umfpack library". The error thrown back is:
> In function `umfpack_timer': (.text+0x1): undefined reference to
> `SuiteSparse_time'
> Could this be another issue created by the packaged version of umfpack?
> They files are all located in /usr/include and /usr/lib. Would anybody
> recommend installing a stand alone version of umfpack instead of trying
> to figure out how to solve this issue?

Probably, that test does not work with the latest version of 
suitesparse; I'm still using 3.4.0.  We'll look into that.

> * SuperLU 4.3 doesn't work, I think Patrick Rix' patch from 31/05/2012
> ([MBDyn-users] Patch for compilation with SuperLU) possibly solves some
> issues (for instance, util.h is named slu_util.h), but I did not test this.

We haven't checked superlu for ages.  I suggest you explicitly disable 
it (--with-superlu=no)

> Has anybody tried building with openBLAS (a goto-blas replacement)? It
> should hold a performance upgrade over standard BLAS.

Not in ages.  Note that BLAS are only used in conjunction with the 
lapack direct dense linear solver, which is outperformed by the "naive" 
solver for typical (sparse) problems with more than 50-60 equations, or 
when using direct eigenanalysis, which should not greatly suffer from 
less than optimal BLAS.

> What would the sentiment be if I set up an un-official mirror of the
> source on github, based upon the code drops on the mbdyn website? Each
> commit would than correspond to a new released mbdyn version.

The license does not prevent it.  But please make it clear that it is 
unofficial, and pushes to that repository will be ignored by the project.

Sincerely, p.

Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano

More information about the MBDyn-users mailing list