I am trying to build Open MPI 1.3.2 with ifort 11.0.074 and icc/icpc
11.0.083 (the Intel compilers) on a quad-core AMD Opteron workstation
running CentOS 4.4. I have no problems on this same machine if I use
ifort with gcc/g++ instead of icc/icpc. Configure seems to work ok
even
though icc and icpc are detected as GNU compilers.
CC=icc CXX=icpc FC=ifort F77=ifort ./configure --disable-shared
--enable-static --prefix=/opt/intelsoft/openmpi/openmpi-1.3.2
Greetings Dave. I tried this configuration earlier this morning and
had no problem. :-(
(also, I'm not sure what happened, but somehow your attachments came
through as uncompressed and inline, meaning everyone on the list got a
3MB+ email)
However, when I run 'make' it has trouble in the opal/asm directory:
libtool: compile: icc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../orte/include -I../../ompi/include
-I../../opal/mca/paffinity/linux/plpa/src/libplpa -I../.. -O3 -DNDEBUG
-finline-functions -fno-strict-aliasing -restrict -MT atomic-asm.lo -
MD
-MP -MF .deps/atomic-asm.Tpo -c atomic-asm.S -o atomic-asm.o
Unknown flag -x
Unknown flag -a
Unknown flag -s
Unknown flag -s
Unknown flag -e
Unknown flag -m
Unknown flag -b
Unknown flag -l
Unknown flag -e
Unknown flag -r
Unknown flag --
Unknown flag -w
Unknown flag -i
Unknown flag -t
Unknown flag -h
Unknown flag --
Unknown flag -c
Unknown flag -p
Unknown flag -p
Unknown flag -F
Hmm. I find it odd that that -xassembler... flag does not appear in
OMPI's output -- it leads me to believe that it's somehow being
inserted under the covers by icc (or something else?). When I built
with icc 11.0 v083 this morning, here's the relevant parts from my
"make" output:
libtool: compile: icc -DHAVE_CONFIG_H -I. -I../../opal/include -
I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/
linux/plpa/src/libplpa -I../.. -O3 -DNDEBUG -finline-functions -fno-
strict-aliasing -restrict -pthread -fvisibility=hidden -MT asm.lo -MD -
MP -MF .deps/asm.Tpo -c asm.c -o asm.o
rm -f atomic-asm.S
ln -s "../../opal/asm/generated/atomic-amd64-linux.s" atomic-asm.S
depbase=`echo atomic-asm.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool --mode=compile icc -DHAVE_CONFIG_H -I. -I../../
opal/include -I../../orte/include -I../../ompi/include -I../../opal/
mca/paffinity/linux/plpa/src/libplpa -I../.. -O3 -DNDEBUG -
finline-functions -fno-strict-aliasing -restrict -MT atomic-asm.lo -MD
-MP -MF $depbase.Tpo -c -o atomic-asm.lo atomic-asm.S &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile: icc -DHAVE_CONFIG_H -I. -I../../opal/include -
I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/
linux/plpa/src/libplpa -I../.. -O3 -DNDEBUG -finline-functions -fno-
strict-aliasing -restrict -MT atomic-asm.lo -MD -MP -MF .deps/atomic-
asm.Tpo -c atomic-asm.S -o atomic-asm.o
/bin/sh ../../libtool --tag=CC --mode=link icc -O3 -DNDEBUG -
finline-functions -fno-strict-aliasing -restrict -pthread -
fvisibility=hidden -export-dynamic -o libasm.la asm.lo atomic-
asm.lo -lnsl -lutil
libtool: link: ar cru .libs/libasm.a asm.o atomic-asm.o
libtool: link: ranlib .libs/libasm.a
libtool: link: ( cd ".libs" && rm -f "libasm.la" && ln -s "../
libasm.la" "libasm.la" )
I can't find any hint of the reported "Unknown flags". What's more is
the opal/asm/generated/atomic-amd64-linux.s file is now empty (file
size
is zero) thus breaking subsequent builds (i.e. with gcc). In order to
get the file back I have to re-extract from the source tarball. If I
execute 'make' again (no 'make clean') the compilation will complete
successfully but will make an empty libasm.a:
Erm -- that's weird. So when you extract the tarballs, atomic-amd64-
linux.s is non-empty (as it should be), but after a failed build, it's
file length 0?
Notice that during the build process, we sym link atomic-amd64-linux.s
to atomic-asm.S (I see that happening in your build output as well).
So if the compiler is barfing when compiling atomic-asm.S, perhaps
it's also wiping out the file...? That would be darn weird, though...
However, even after I get Open MPI to compile, 'make check' will give
the following results:
libtool: link: icc -DOMPI_DISABLE_INLINE_ASM -O3 -DNDEBUG
-finline-functions -fno-strict-aliasing -restrict -pthread
-fvisibility=hidden -o atomic_barrier_noinline
atomic_barrier_noinline-atomic_barrier_noinline.o -Wl,--export-dynamic
../../opal/asm/.libs/libasm.a -lnsl -lutil -pthread
ipo: warning #11010: file format not recognized for
../../opal/asm/.libs/libasm.a, possible linker script
atomic_barrier_noinline-atomic_barrier_noinline.o(.text+0x29): In
function `main':
: undefined reference to `opal_atomic_mb'
Yes, this is not surprising if the .s file is empty -- it makes an
empty .o file, and therefore those symbols just aren't defined.
--
Jeff Squyres
Cisco Systems
