[Beowulf] Weird problem with mpp-dyna

[Joe Landman]

Joshua Baker-LePain wrote:
> On Wed, 14 Mar 2007 at 2:54pm, Joe Landman wrote
> 
>> Joshua Baker-LePain wrote:
>>
>>> They also provide the matching pre-compiled LAM/MPI libraries on 
>>> their site. For a fun little wrinkle, RHEL/CentOS ships LAM/MPI 
>>> 7.0.6. However, the spec file in their RPM does *not* include the 
>>> --enable-shared flag. IOW, the OS vendor's LAM/MPI package has no .so 
>>> files.
>>
>> I rebuilt this (the LAM) for our customer.  Works nicely now.
> 
> What compiler did you build it with?

3.2.3 as I remember ... hang on ... yup 3.2.3.

>  I just tried to build it with gcc 
> it bombs out building the shared libraries:
> 
> g++ -shared 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crti.o 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/crtbeginS.o .libs/mpicxx.o 
> e.libs/intercepts.o .libs/pmpicxx.o .libs/op.o .libs/comm.o 
> .libs/intracomm.o .libs/topology.o .libs/intercomm.o .libs/info.o 
> .libs/win.o .libs/request.o .libs/group.o .libs/datatype.o 
> .libs/status.o .libs/errhandler.o .libs/exception.o .libs/functions.o 
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6 
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64 
> -L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../.. -L/lib/../lib64 
> -L/usr/lib/../lib64 -lstdc++ -lm -lpthread -lc -lgcc_s 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/crtendS.o 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crtn.o -o 
> .libs/liblammpi++.so.0.0.0
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crti.o(.init+0x0): 
> In function `_init':
> : multiple definition of `_init' 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crti.o(.init+0x0): 
> first defined here 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crti.o(.fini+0x0): 
> In function `_fini':
> : multiple definition of `_fini' 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/crti.o(.fini+0x0): 
> first defined here 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/crtbeginS.o(.data.rel+0x0): 
> multiple definition of `__dso_handle' 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/crtbeginS.o(.data.rel+0x0): first 
> defined here
> collect2: ld returned 1 exit status
> make[3]: *** [liblammpi++.la] Error 1
> make[3]: Leaving directory `/spare/jlb/lam-7.0.6/share/mpi/cxx'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/spare/jlb/lam-7.0.6/share/mpi'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/spare/jlb/lam-7.0.6/share'
> make: *** [all-recursive] Error 1

Yeah we had all manner of problems with the 3.4.x gcc.  Doesn't build 
mpiblast correctly.  Some sort of library search path issue (or 
incorrectly built libs).  Note that you are getting a multiple 
definitions problem: : multiple definition of `_init'

I seem to remember needing to update libtool and a few others.

> 
>> Try an ldd against mpp-dyna-big-long-name
> 
> [jlb at harry tmp2]$ ldd 
> /usr/local/lstc/bin64/mpp971_d_7600.2.398_PGI_linux86-64_lam703
>         liblamf77mpi.so.0 => /usr/local/lstc/lib64/liblamf77mpi.so.0 

Hmmm...

> (0x0000002a95575000)
>         libmpi.so.0 => /usr/local/lstc/lib64/libmpi.so.0 

Looks like it is finding the shared libraries to link against.  If you do an

	rpm -qf /usr/local/lstc/lib64/libmpi.so.0

I assume it is not part of any RPM (e.g. you put this here yourself), 
but what you pulled from the LSTC site?




-- 

Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: landman at scalableinformatics.com
web  : http://www.scalableinformatics.com
phone: +1 734 786 8423
fax  : +1 734 786 8452 or +1 866 888 3112
cell : +1 734 612 4615