Project

General

Profile

Bug #1933

Build issue with MAUS v2.9.0

Added by Nugent, John about 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Build System
Target version:
-
Start date:
18 May 2017
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

I am trying to build the latest MAUS release on a data disk at Glasgow however the build fails. I have uploaded the install.log. In it I see that matplotlib fails to build. I had a look on the install page for MAUS. The suggestion there is if matplotlib fails to build then you should ensure that you have forwarded your X11 when building. I have done this and it returns the same error. Any pointers or suggestions in resolving this issue would be appreciated. I am building on Scientific Linux 5.11.


Files

install.log (18.6 MB) install.log Nugent, John , 18 May 2017 09:24
error.log (4.39 KB) error.log Nugent, John , 18 May 2017 16:21
#1

Updated by Nugent, John about 7 years ago

  • Private changed from Yes to No
#2

Updated by Dobbs, Adam about 7 years ago

Hi John, did you start from a completely clean installation directory? Upgrading in place for this release would be difficult, a clean start is best. The issue is that a dependency of matplotlib, the python module subprocess32, is failing to compile. If you source the MAUS environment and then do:

pip install subprocess32

that should cleanly highlight the failure.

#3

Updated by Nugent, John about 7 years ago

Thanks for having a look at this Adam. I started with a completely fresh build, new pull from Git new third parties everything. I ran

pip install subprocess32

and I have attached the error log I get from this. You are right, this is the error I was looking at yesterday. I'm trying to determine what is causing this part to fall over. Is it my linux distro, lack of python devel package? I am just a user (not root) so I can't control those things in my environment. Is there anything local that I can try?

#4

Updated by Dobbs, Adam about 7 years ago

OK, done some researching, seems this is a known bug affect subprocess32 on older systems. There is a hack solution here:

https://github.com/google/python-subprocess32/issues/12

John, can you try the solution listed here, then check by trying to build the python extras once you have made the hack and installed subprocess manually:

bash third_party/bash/40python_extras.bash -gi

If that works you can then try rerunning the full install script.

Let me know...

#5

Updated by Nugent, John about 7 years ago

Hi Adam,

long story so here goes. I had a discussion with the IT guys at Glasgow after which I decided to upgrade to a new linux box and operating system. I am now on a newer machine and running CentOS 7.3.1611. I have got the newest version of MAUS to build on my machine however I had to comment out the line

ln -s ../lib/python2.7/site-packages/numpy/core/include/numpy numpy

in the third party bash script in order to get it to work. That is the good news. However whenever I now try and use this new installation of MAUS when compiling my analysis scripts. I get an error with the libraries such as

/usr/bin/ld: MCSAnalysis.o: undefined reference to symbol '_ZN4Json5ValueC1Ei'
/afs/phas.gla.ac.uk/user/j/jnugent/private/PhD_Year_1/software/MAUS-v2.9.0/third_party/install/lib/libjson.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [MCSUnfolding] Error 1

For this I am confused. MAUS has built successfully, the third parties have built successfully, the libraries are there and the Makefile finds them. This Makefile worked fine previously so is there some fundamental incompatibility here? Any pointers would be appreciated as I am at a dead end at the moment.

Cheers,
John

#6

Updated by Nugent, John about 7 years ago

Never mind Adam, took a fair bit of hacking but I got it working. Thanks anyway.

#7

Updated by Nugent, John about 7 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100
#8

Updated by Dobbs, Adam about 7 years ago

Hi John - glad you fixed it. Did you figure out what the issue with CentOS 7 was in the end? I install on that OS and it normally gives me no hassle so I'm curious...

#9

Updated by Nugent, John about 7 years ago

I was running a CentOS machine on the Glasgow cluster. Turns out the system admin install is a bit "raw". A few libraries were not there and others were in different locations. I had to go through and find each one and update my Makefile but with a bit of hacking I managed to get it going.

Cheers,
John

Also available in: Atom PDF