Linking Error

[Matt Ellis]

Hello,

I have a working version of a Yak/OpenMC coupling on my desktop that I wanted to move to fission to run a large benchmark problem.  Unfortunately, I wasn't even able to get through compiling.  Everything compiles fine on my desktop, but with the same code on fission I get the following printouts during the linking step:

/usr/bin/ld: skipping incompatible /lib/libz.so when searching for -lz

/usr/bin/ld: cannot find -l-L/apps/local/neams/compiler/gcc/4.6.3/gcc/opt/lib64/../lib64

It is worth noting that when I just compile and link yak (no OpenMC) I still get the /lib/libz.so warnings but everything else works fine.  

I echoed out libmesh_libs during the linking process, and I can't find the exact string it is looking for in the error.  I only see -L/apps/local/neams/compiler/gcc/4.6.3/gcc/opt/lib64 (no -l at the front).  Also, the directory shown in the error is valid.

Last summer at INL we did find an error in the libtool file in libmesh that prevented us from compiling moose with openmc on a Linux Desktop.  The cause was in ~/projects/trunk/libmesh/installed/contrib/bin/libtool (old directory structure). There was a -l -l statement that should have just been a -l (according to our fix).  However, this fix is no longer needed on my linux desktop but the symptoms of getting a linking error with "-l -L ...." are similar.

I am unfamiliar with how the moose-dev-gcc module is put together.  Does anyone have any ideas why I am getting this linking error?

Thanks for the help!

--

Matthew S. Ellis I Nuclear Engineering Graduate Research Assistant I mell...@gmail.edu

NW12-312 Cambridge, MA 02139 

[Peterson, JW]

On Wed, Apr 16, 2014 at 8:17 PM, Matt Ellis <mell...@mit.edu> wrote:

Hello,

I have a working version of a Yak/OpenMC coupling on my desktop that I wanted to move to fission to run a large benchmark problem.  Unfortunately, I wasn't even able to get through compiling.  Everything compiles fine on my desktop, but with the same code on fission I get the following printouts during the linking step:

/usr/bin/ld: skipping incompatible /lib/libz.so when searching for -lz

/usr/bin/ld: cannot find -l-L/apps/local/neams/compiler/gcc/4.6.3/gcc/opt/lib64/../lib64

It is worth noting that when I just compile and link yak (no OpenMC) I still get the /lib/libz.so warnings but everything else works fine.  

If Yak/MOOSE/libmesh links without OpenMC, then I would guess the problem is due to a Fortran compiler misconfiguration.

Could you have a look in your trunk/moose/libmesh/installed/lib/libmesh_opt.la file and see if the offending PATH is in the dependency_libs line?

 

Last summer at INL we did find an error in the libtool file in libmesh that prevented us from compiling moose with openmc on a Linux Desktop.  The cause was in ~/projects/trunk/libmesh/installed/contrib/bin/libtool (old directory structure). There was a -l -l statement that should have just been a -l (according to our fix).  However, this fix is no longer needed on my linux desktop but the symptoms of getting a linking error with "-l -L ...." are similar.

I think you are referring to https://github.com/libMesh/libmesh/issues/107, which was caused by an interaction between mpich compiler scripts and the gfortran compiler.  It's possible this same thing is happening again in a slightly different way this time.  Can you send me the output of running

mpif90 -shared -g -v

on fission?

Thanks,

John

[Peterson, JW]

On Thu, Apr 17, 2014 at 11:04 AM, Matt Ellis <mell...@mit.edu> wrote:

John,

I did indeed forget the first two lines.  I was rushing to send that email before I had to leave for a meeting.  However, I believe I have the same text as you sent (as shown below):

mpif90 for MVAPICH2 version 1.9b

Driving: gfortran -L/lib -L/lib -L/lib -Wl,-rpath,/lib -L/lib -Wl,-rpath,/lib -L/lib -L/lib -shared -g -v -I/apps/projects/moose/stack/fbuild/mvapich/gcc-1.9b/include -I/apps/projects/moose/stack/fbuild/mvapich/gcc-1.9b/include -L/apps/projects/moose/stack/fbuild/mvapich/gcc-1.9b/lib -lmpichf90 -Wl,-rpath -Wl,/apps/projects/moose/stack/fbuild/mvapich/gcc-1.9b/lib -lmpich -lopa -lmpl -lrdmacm -libumad -libverbs -ldl -lrt -l gfortran -lm -lpthread -l gfortran -l m -shared-libgcc

Using built-in specs.

Sorry about the errors in the previous email.  Let me know if you think that you can fix the error.  

It should be fixed in upstream [0].  If you would like to try it out now instead of waiting for the next libmesh update, I can walk you through the steps of checking out libmesh from github...

[0]: https://github.com/libMesh/libmesh/commit/8901bce4ef23adba0fbda6f8ec56f6a0483f5482

--
John

[Matt Ellis]

Thanks!

If you have time, I'd like to try to check out libmesh from github.  

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Matthew S. Ellis I Nuclear Engineering Graduate Research Assistant I mell...@mit.edu

NW12-312 Cambridge, MA 02139 I mob 717.669.5547

[Peterson, JW]

On Sat, Apr 19, 2014 at 8:10 PM, Matt Ellis <mell...@mit.edu> wrote:

John,

It looks like everything compiles correctly now with the changes you made.  Thanks!

Great, thanks for letting me know.

In case anyone is interested, there are now instructions for building upstream libmesh available on the mooseframework.org wiki:

http://mooseframework.org/wiki/LibMeshUpstream/

--
John