Build Issue with -lgomp flag

[shosty]

Hi! I'm trying to install MSMbuilder2.7.0 on our dept. linux cluster, using the --prefix installation flag, and continue getting the following error when attempting to install:

error: Command "gcc -pthread -shared build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/src/ext/asa/_asamodule.o build/temp.linux-x86_64-2.7/src/ext/asa/asa.o build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/fortranobject.o -lgomp -o build/lib.linux-x86_64-2.7/msmbuilder/_asa.so" failed with exit status 1

However, if I try executing the faulty command on its own (from the command line) it compiles and produces _asa.so correctly. I think there is a problem with some linked libraries but I can't figure out why it works fine on its own but not during install.

Here's some more info on the machine:

python Python 2.7.3 (default, Mar 19 2013, 12:42:39) [GCC 4.4.5 20110214 (Red Hat 4.4.5-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

echo $PATH /net/antonin/home/chakra/savol/local/bin:/csb/sl64/torque/bin:/csb/sl64/torque/sbin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/net/antonin/home/chakra/savol/bin

echo $PYTHONPATH /net/antonin/usr/local/anaconda/lib/python2.7/site-packages:/net/antonin/home/chakra/savol/lib/python2.7/site-packages

echo $LD_LIBRARY_PATH /csb/sl64/torque/lib:/usr/lib/gcc/x86_64-redhat-linux/4.4.4/

I added usr/lib/gcc/x86_64-redhat-linux/4.4.4/ to the LD_LIBRARY_PATH because the gomp libraries are located there and executing the offending command from the command line >> gcc -pthread -shared ..... /msmbuilder/_asa.so failed unless either $PATH or $LD_LIBRARY_PATH pointed there. Using -L also worked but I don't know how to tell the install compilation to add the linked library to gcc commands. Likewise, >> alias gcc="gcc -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4/" worked at the command line but didn't prevent the compilation error during install.

Any suggestions for this install error would be much appreciated. Many thanks!

[rmcgibbo]

I haven't seen this before. If running the command manually works, then you can get a complete build by running the commands like

$ python setup.py install
$ run-failing-gcc-command-manually
$ python setup.py install

libgomp is part of gcc. If you think your cluster's gomp installation or default directories are broken, I would recommend talking to the department sysadmins. Otherwise, adding to your LD_LIBRARY_PATH seems pretty reasonable. You can also turn off OpenMP acceleration in msmbuilder by opening up setup.py and changing this function to always return False, False.

[shosty]

Thank you very much for the suggestions. They enabled me to get past the -lgomp error, but I'm facing a new installation error now:

python setup.py install --prefix=$HOME >> build.out

gcc -pthread -shared build/temp.linux-x86_64-2.7/src/ext/molfile_plugin/dcdplugin_s.o -lm -o build/lib.linux-x86_64-2.7/msmbuilder/dcdplugin_s .so /usr/bin/ld: /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a(s_sin.o): relocation R_X86_64_32S a gainst .rodata' can not be used when making a shared object; recompile with -fPIC /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status /usr/bin/ld: /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a(s_sin.o): relocation R_X86_64_32S a gainst.rodata' can not be used when making a shared object; recompile with -fPIC /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status

Google searches suggest there is another problem with the shared libraries, but I haven't been able to fix it. I realize this may be outside your purview but just wanted to write since your first response was so helpful. Any suggestions much appreciated, and thanks again!

On Mar 10, 2014, at 6:31 PM, Robert McGibbon notifications@github.com wrote:

I haven't seen this before. If running the command manually works, then you can get a complete build by running the commands like

$ python setup.py install $ run-failing-gcc-command-manually $ python setup.py install libgomp is part of gcc. If you think your cluster's gomp installation or default directories are broken, I would recommend talking to the department sysadmins. Otherwise, adding to your LD_LIBRARY_PATH seems pretty reasonable. You can also turn off OpenMP acceleration in msmbuilder by opening up setup.py and changing this function to always return False, False.

— Reply to this email directly or view it on GitHub.

[kyleabeauchamp]

Maybe try adding the fPIC flag when you run the manual gcc command?

[rmcgibbo]

Can you tell me a little bit about your system? What flavor of linux and version of gcc are you using? Do you have any environment variables like CFLAGS, LDFLAGS, or CC set?

In your first post, it appeared that you were using gcc 4.4.4, but in your latest post, the math library being linked against is from gcc 4.8.2. This seems sketchy to me.

[shosty]

I much appreciate the assistance, thanks. Below is some detail on my machine. CC, LDFLAGS, and CFLAGS are not set, although CFLAGS gets set by the Makefile in the molfile_plugin dir (see below). I had originally set LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.4.4 because the gomp libraries were there, but I've disabled OpenMP (which eliminates the gomp error) and still get the: "relocation R_X86_64_32S a gainst `.rodata' can not be used when making a shared object; recompile with -fPIC"

and

"could not read symbols: Bad value"

errors (given in full below). I tried manually executing the offending command with an added -fPIC flat but still produced the same error.

Googling found the same error here, where the proposed fix is "turn the to-be-built shared library into a static one". I am not sure what operations performed on libm.a or modifications to setup.py would do that; thought you might have an opinion about this being the right course of inquiry…

Thank you again for your time and suggestions!

cat /etc/*-release LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Scientific Linux release 6.4 (Carbon) Scientific Linux release 6.4 (Carbon)

echo $PATH $HOME/local/bin:/csb/sl64/torque/bin:/csb/sl64/torque/sbin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:$HOME/bin

gcc --version gcc (GCC) 4.8.2

echo $LD_LIBRARY_PATH /csb/sl64/torque/lib

grep CFLAGS $HOME/msmbuilder-2.7.0/src/ext/molfile_plugin/Makefile CFLAGS=-I include -fPIC -Wall -O2 -m64

---

(re-pasted error)

python setup.py install --prefix=$HOME gcc -pthread -shared build/temp.linux-x86_64-2.7/src/ext/molfile_plugin/dcdplugin_s.o -lm -o build/lib.linux-x86_64-2.7/msmbuilder/dcdplugin_s .so /usr/bin/ld: /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a(s_sin.o): relocation R_X86_64_32S a gainst .rodata' can not be used when making a shared object; recompile with -fPIC /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status /usr/bin/ld: /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a(s_sin.o): relocation R_X86_64_32S a gainst.rodata' can not be used when making a shared object; recompile with -fPIC /net/antonin/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libm.a: could not read symbols: Bad value

collect2: error: ld returned 1 exit status

On Mar 12, 2014, at 5:10 PM, Robert McGibbon notifications@github.com wrote:

Can you tell me a little bit about your system? What flavor of linux and version of gcc are you using? Do you have any environment variables like CFLAGS, LDFLAGS, or CC set?

In your first post, it appeared that you were using gcc 4.4.4, but in your latest post, the math library being linked against is from gcc 4.8.2. This seems sketchy to me.

On Mar 12, 2014, at 5:10 PM, Robert McGibbon notifications@github.com wrote:

Can you tell me a little bit about your system? What flavor of linux and version of gcc are you using? Do you have any environment variables like CFLAGS, LDFLAGS, or CC set?

In your first post, it appeared that you were using gcc 4.4.4, but in your latest post, the math library being linked against is from gcc 4.8.2. This seems sketchy to me.

On Mar 12, 2014, at 5:10 PM, Robert McGibbon notifications@github.com wrote:

Can you tell me a little bit about your system? What flavor of linux and version of gcc are you using? Do you have any environment variables like CFLAGS, LDFLAGS, or CC set?

In your first post, it appeared that you were using gcc 4.4.4, but in your latest post, the math library being linked against is from gcc 4.8.2. This seems sketchy to me.

— Reply to this email directly or view it on GitHub.

[shosty]

Okay, it seems like the libm problems were caused by broken links to the shared libraries. Executing the failing commands manually works now following new links and installation completed normally. I really appreciate all the help! Thank you!

[kyleabeauchamp]

I'm glad things are working, feel free to re-open the issue if you continue to have problems.