Actually, I think that mpicc is doing exactly the Right Thing.
If you don't specify -m32, the underlying compiler is going to default
to 64 bit builds (and libraries), so it naturally tries the /usr/lib64
stuff. But when you supply -m32, it knows that you want to do 32 bit
builds and uses /usr/lib.
This is the same as it would be if you used gcc natively (remember that
mpicc is simply a wrapper around invoking the underlying compiler --
all it does is maniuplate your argv and then invoke the underlying
compiler).
On Sep 28, 2005, at 12:32 PM, Nathan DeBardeleben wrote:
FYI, this worked and OMPI compiled but mpicc tries to use the 64bit
libraries. Doesn't appear that -m32 is being passed in the configure
or
whatever down into mpicc. Once I dropped -m32 on my mpicc I was able
to
do 32bit compiles using mpicc on a 64bit machine.
Looks like there's definately some libtool problems running around.
[sparkplug]~/ompi-test > mpicc -o test-mpi test-mpi.c
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-
linux/bin/ld:
skipping incompatible /home/ndebard/local/ompi/lib/libmpi.so when
searching for -lmpi
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-
linux/bin/ld:
cannot find -lmpi
collect2: ld returned 1 exit status
[sparkplug]~/ompi-test >
[sparkplug]~/ompi-test > mpicc -showme
gcc -I/home/ndebard/local/ompi/include
-I/home/ndebard/local/ompi/include/openmpi
-I/home/ndebard/local/ompi/include/openmpi/opal
-I/home/ndebard/local/ompi/include/openmpi/orte
-I/home/ndebard/local/ompi/include/openmpi/ompi
-L/home/ndebard/local/ompi/lib -lmpi -lorte -lopal -lutil -lnsl -ldl
-Wl,--export-dynamic -lm -lutil -lnsl -ldl
[sparkplug]~/ompi-test >
[sparkplug]~/ompi-test >
[sparkplug]~/ompi-test > mpicc -m32 -o test-mpi test-mpi.c
[sparkplug]~/ompi-test >
-- Nathan
Correspondence
---------------------------------------------------------------------
Nathan DeBardeleben, Ph.D.
Los Alamos National Laboratory
Parallel Tools Team
High Performance Computing Environments
phone: 505-667-3428
email: ndeb...@lanl.gov
---------------------------------------------------------------------
Ralf Wildenhues wrote:
Hi Nathan, Jeff,
* Jeff Squyres wrote on Tue, Sep 27, 2005 at 09:39:59PM CEST:
This looks like it *might* be a libtool problem -- it's picking up
the
/usr/lib64/libstdc++.so when you're compiling in 32 bit mode (and
therefore barfing).
Yep, I think it is.
Can you send the libtool command that immediately preceded this link
line?
As a workaround, you should be able to --disable-cxx to disable the
MPI
C++ bindings, and therefore skip building in this tree.
Other, better-suited workarounds: either
- remove the 64bit paths from compiler_lib_search_path and
sys_lib_search_path_spec in the generated libtool script(s)
(note these variables are set both at the very beginning,
and at the very end, once for each source file language),
or
- link with "LDFLAGS=-L/usr/lib", if /usr/lib is where your
32-bit libstdc++.so is located.
We're not really sure yet how to fix this for all distributions.
Sorry for the inconvenience,
Ralf
On Sep 27, 2005, at 3:23 PM, Nathan DeBardeleben wrote:
So is this an error or am I configuring wrong?
Here's my configure:
[sparkplug]~/ompi > ./configure CFLAGS=-m32 FFLAGS=-m32
CXXFLAGS=-m32
--without-threads --prefix=/home/ndebard/local/ompi
--with-devel-headers --without-gm
I've also tried adding --build=i586-suse-linux, that didn't help
either.
Basically the compile eventually ends here:
g++ -DHAVE_CONFIG_H -I. -I. -I../../../include -I../../../include
-I../../../include -I../../.. -I../../.. -I../../../include
-I../../../opal -I../../../orte -I../../../ompi -m32 -g -Wall
-Wundef
-Wno-long-long -finline-functions -MT comm.lo -MD -MP -MF
.deps/comm.Tpo -c comm.cc -fPIC -DPIC -o .libs/comm.o
/bin/sh ../../../libtool --mode=link g++ -m32 -g -Wall -Wundef
-Wno-long-long -finline-functions -export-dynamic -o
libmpi_cxx.la
-rpath /home/ndebard/local/ompi/lib mpicxx.lo intercepts.lo
comm.lo
-lm -lutil -lnsl
g++ -shared -nostdlib
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../lib/crti.o
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/32/crtbeginS.o
.libs/mpicxx.o .libs/intercepts.o .libs/comm.o -lutil -lnsl
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/32
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-
suse-
linux/lib/../lib
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-
suse-
linux/lib
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../lib
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../.. -L/lib/../lib
-L/usr/lib/../lib /usr/lib64/libstdc++.so -lm -lc -lgcc_s_32
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/32/crtendS.o
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../lib/crtn.o
-m32 -Wl,-soname -Wl,libmpi_cxx.so.0 -o .libs/libmpi_cxx.so.0.0.0
/usr/lib64/libstdc++.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [libmpi_cxx.la] Error 1
make[3]: Leaving directory `/home/ndebard/ompi/ompi/mpi/cxx'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ndebard/ompi/ompi/mpi'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ndebard/ompi/ompi'
make: *** [all-recursive] Error 1
[sparkplug]~/ompi >
I'm having problems I think might be 64bit related and want to
prove it
by building in 32bit mode.
Oh, here's some basics if it helps.
[sparkplug]~/ompi > cat /etc/issue
Welcome to SuSE Linux 9.1 (x86-64) - Kernel \r (\l).
[sparkplug]~/ompi > uname -a
Linux sparkplug 2.6.10 #4 SMP Wed Jan 26 11:50:00 MST 2005 x86_64
x86_64 x86_64 GNU/Linux
[sparkplug]~/ompi >
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
