Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Intel C (icc) 11.0.083 compile problem
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-06-17 16:29:43


> 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