[MBDyn-users] compiling on Arch Linux

David Verelst david.verelst at gmail.com
Mon Sep 22 19:22:23 CEST 2014

Dear Pierangelo,

Thanks for the clarifications. For those interested, the Arch Linux AUR
package is available at:
The package builds (without umfpack support) and I can run the some of the
example problems (including the python interface).

Regarding the python print statement: I have not tried to build against
python 3.x, I was just expecting that test to fail since it would result in
calling python 3. Hence my conclusion that test block was never actually

I will not establish a public git repository that only holds the source
archives already present at mbdyn.org. I guess it will not add anything new
compared to what is already available :-)

Best regards,

On 22 September 2014 16:07, Pierangelo Masarati <
pierangelo.masarati at polimi.it> wrote:

> 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
> _______________________________________________
> MBDyn-users mailing list
> MBDyn-users at mbdyn.org
> https://mail.mbdyn.org/cgi-bin/mailman/listinfo/mbdyn-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mbdyn.org/pipermail/mbdyn-users/attachments/20140922/fe1bd408/attachment-0001.html>

More information about the MBDyn-users mailing list