Hi Jeff

Thank you for your suggestion!
You're right.
It works with '-tp=shanghai-64', which is great.
A snippet of the make log where I had errors before is included below,
the crucial line being:

libtool: link: pgcc -shared  -fpic -DPIC  .libs/dummy.o   -lnsl -lutil -lc  
-tp=shanghai-64   -Wl,-soname -Wl,libopenmpi_malloc.so.0 -o 
.libs/libopenmpi_malloc.so.0.0.0

Somehow the OMPI 1.4.4 parses correctly the syntax with the equal sign,
but leaves it at '-tp' only if there is no equal sign.
If I understood right the patch you mentioned, the intent was to allow both 
syntaxes.

FYI, I just checked the man pages of various PGI compiler releases,
and they seem to have changed the syntax from '-tp target_processor' 
to '-tp=target_processor' in release 11.  Up to release 10 the syntax was the
former, although release 11 seems to accept both syntaxes.

So, if one is not using the latest syntax and the latest PGI version,
one is out of luck with OpenMPI 1.4.4, or must not use the '-tp 
target_processor' flag, right?
Could the patch be patched to make the parsing a bit more forgiving? 
[Maybe I am asking for too much, since 1.4.4 is probably the final release of 
the 1.4 series.]

Many thanks for your help.
Gus Correa

#################################
make[2]: Entering directory 
`/home/swinst/openmpi/1.4.4/openmpi-1.4.4/build_pgi-11.7/opal/mca/memory/ptmalloc2'
source='../../../../../opal/mca/memory/ptmalloc2/dummy.c' object='dummy.lo' 
libtool=yes \
        DEPDIR=.deps depmode=none /bin/sh ../../../../../config/depcomp \
        /bin/sh ../../../../libtool --tag=CC   --mode=compile pgcc 
-DHAVE_CONFIG_H -I. -I../../../../../opal/mca/memory/ptmalloc2 
-I../../../../opal/include -I../../../../orte/include 
-I../../../../ompi/include 
-I../../../../opal/mca/paffinity/linux/plpa/src/libplpa  -DMALLOC_DEBUG=0 
-D_GNU_SOURCE=1 -DUSE_TSD_DATA_HACK=1 -DMALLOC_HOOKS=1 
-I../../../../../opal/mca/memory/ptmalloc2/sysdeps/pthread  
-I../../../../../opal/mca/memory/ptmalloc2/sysdeps/generic -I../../../../.. 
-I../../../.. -I../../../../../opal/include -I../../../../../orte/include 
-I../../../../../ompi/include  -D_REENTRANT  -DNDEBUG -tp=shanghai-64 -fast 
-Mfprelaxed  -c -o dummy.lo ../../../../../opal/mca/memory/ptmalloc2/dummy.c
libtool: compile:  pgcc -DHAVE_CONFIG_H -I. 
-I../../../../../opal/mca/memory/ptmalloc2 -I../../../../opal/include 
-I../../../../orte/include -I../../../../ompi/include 
-I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -DMALLOC_DEBUG=0 
-D_GNU_SOURCE=1 -DUSE_TSD_DATA_HACK=1 -DMALLOC_HOOKS=1 
-I../../../../../opal/mca/memory/ptmalloc2/sysdeps/pthread 
-I../../../../../opal/mca/memory/ptmalloc2/sysdeps/generic -I../../../../.. 
-I../../../.. -I../../../../../opal/include -I../../../../../orte/include 
-I../../../../../ompi/include -D_REENTRANT -DNDEBUG -tp=shanghai-64 -fast 
-Mfprelaxed -c ../../../../../opal/mca/memory/ptmalloc2/dummy.c  -fpic -DPIC -o 
.libs/dummy.o
libtool: compile:  pgcc -DHAVE_CONFIG_H -I. 
-I../../../../../opal/mca/memory/ptmalloc2 -I../../../../opal/include 
-I../../../../orte/include -I../../../../ompi/include 
-I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -DMALLOC_DEBUG=0 
-D_GNU_SOURCE=1 -DUSE_TSD_DATA_HACK=1 -DMALLOC_HOOKS=1 
-I../../../../../opal/mca/memory/ptmalloc2/sysdeps/pthread 
-I../../../../../opal/mca/memory/ptmalloc2/sysdeps/generic -I../../../../.. 
-I../../../.. -I../../../../../opal/include -I../../../../../orte/include 
-I../../../../../ompi/include -D_REENTRANT -DNDEBUG -tp=shanghai-64 -fast 
-Mfprelaxed -c ../../../../../opal/mca/memory/ptmalloc2/dummy.c -o dummy.o 
>/dev/null 2>&1
/bin/sh ../../../../libtool --tag=CC   --mode=link pgcc  -DNDEBUG 
-tp=shanghai-64 -fast -Mfprelaxed   -export-dynamic   -o libopenmpi_malloc.la 
-rpath /home/sw/openmpi/1.4.4/pgi-11.7/lib dummy.lo  -lnsl -lutil  
libtool: link: pgcc -shared  -fpic -DPIC  .libs/dummy.o   -lnsl -lutil -lc  
-tp=shanghai-64   -Wl,-soname -Wl,libopenmpi_malloc.so.0 -o 
.libs/libopenmpi_malloc.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libopenmpi_malloc.so.0" && ln -s 
"libopenmpi_malloc.so.0.0.0" "libopenmpi_malloc.so.0")
libtool: link: (cd ".libs" && rm -f "libopenmpi_malloc.so" && ln -s 
"libopenmpi_malloc.so.0.0.0" "libopenmpi_malloc.so")
libtool: link: ar cru .libs/libopenmpi_malloc.a  dummy.o
libtool: link: ranlib .libs/libopenmpi_malloc.a
libtool: link: ( cd ".libs" && rm -f "libopenmpi_malloc.la" && ln -s 
"../libopenmpi_malloc.la" "libopenmpi_malloc.la" )

#################################


On Nov 8, 2011, at 8:57 PM, Jeff Squyres wrote:

> It looks like we added a patch to the libtool bootstrap in the 1.4.4 tarball 
> (because we're using a quite old version of Libtool to build that tarball) in 
> r24224:
> 
>    https://svn.open-mpi.org/trac/ompi/changeset/24224
> 
> This was to close CMR https://svn.open-mpi.org/trac/ompi/ticket/2670, which 
> was the port to v1.4 from the original Trac ticket 
> https://svn.open-mpi.org/trac/ompi/ticket/2586.
> 
> It *looks* like this patch is supposed to allow -tp <foo> to pass through 
> Libtool.
> 
> The Libtool sh here is quite complex; I'm not sure I'm reading it right.  Can 
> you try -tp=shanghai-64 instead of "-tp shanghai-64"?
> 
> 
> On Nov 8, 2011, at 5:14 PM, Gustavo Correa wrote:
> 
>> Thank you, Samuel
>> 
>> I was hoping not to have to change my Gnu auto tools in the cluster.
>> I remain a bit skeptical that libtool is the main culprit.
>> 
>> Somehow OpenMPI 1.4.3 builds fine in the very same computer
>> with the same libtool, same PGI 11.7, same compiler flags.
>> In the OMPI 1.4.3 make log there are several lines with 'libtool: link: 
>> pgcc' followed 
>> by all compiler flags.
>> In addition, the specific line that links libopenmpi_malloc.so, 
>> correctly strips off *all* compiler flags, it doesn't leave the '-tp' behind,
>> hence pgcc can do its job.
>> I would guess this is the right thing to do, no funny optimization flags 
>> chosen by 
>> the user in a malloc library. 
>> Here it is:
>> 
>> libtool: link: pgcc -shared  -fpic -DPIC  .libs/dummy.o   -lnsl -lutil -lc   
>>  -Wl,-soname -Wl,libopenmpi_malloc.so.0 -o .libs/libopenmpi_malloc.so.0.0.0
>> 
>> However, the same setup doesn't work with OMPI 1.4.4.
>> That particular line in the make log is [note the added '-tp']:
>> 
>> libtool: link: pgcc -shared  -fpic -DPIC  .libs/dummy.o   -lnsl -lutil -lc  
>> -tp   -Wl,-soname -Wl,libopenmpi_malloc.so.0 -o 
>> .libs/libopenmpi_malloc.so.0.0.0
>> 
>> Hence, I am more inclined to think that there was a change from  the 1.4.3 
>> to  
>> the 1.4.4 configure script, that somehow forgot how to handle the PGI 
>> quirks, 
>> and is no longer stripping correctly  the user CFLAGS when it links the 
>> libopenmpi_malloc.so library.
>> 
>> I can send the gzipped configure and make logs of 1.4.3 and 1.4.4 if that 
>> helps.
>> I didn't do it so as not to bother the list with bulky files.
>> 
>> Many thanks,
>> Gus Correa
>> 
>> 
>> On Nov 8, 2011, at 4:24 PM, Samuel K. Gutierrez wrote:
>> 
>>> Hi,
>>> 
>>> I think I've seen this before.
>>> 
>>> I can't speak to the details surrounding this issue, but when I upgraded to 
>>> the newest version of libtool, the problem went away <shrug>.
>>> 
>>> Take a look at "Use of GNU m4, Autoconf, Automake, and Libtool" in our 
>>> HACKING file.  libtool-2.4.2.tar.gz **should** work, if that's the problem 
>>> that you are experiencing.
>>> 
>>> I would suggest starting with a fresh source tree, before you try again.
>>> 
>>> Hope that helps,
>>> 
>>> Samuel K. Gutierrez
>>> Los Alamos National Laboratory
>>> 
>>> On Nov 8, 2011, at 2:06 PM, Gustavo Correa wrote:
>>> 
>>>> Dear OpenMPI pros
>>>> 
>>>> When I try to build OpenMPI 1.4.4 with PGI compilers 11.7 [pgcc, pgcc, 
>>>> pgfortran]
>>>> I get the awkward error message on the bottom of this email.
>>>> 
>>>> I say awkward because I assigned the value 'shanghai-64' to the '-tp' flag,
>>>> as you can see from the successful 'libtool:compile' command in the error 
>>>> message.
>>>> However, the subsequent 'libtool:link' command has '-tp' without a value.
>>>> Note that the remaining flags '-fast -Mfprelaxed' were also dropped in the 
>>>> libtool:link command. 
>>>> The 'partial' flag '-tp' is worse than no flag at all, and the pgcc 
>>>> compiler fails.
>>>> 
>>>> By contrast, OpenMPI 1.4.3 builds just fine with  the same compilers and 
>>>> the same compiler flags.
>>>> 
>>>> Is this the revival of an old idiosyncrasy between libtool and PGI?
>>>> Could perhaps the OMPI 1.4.4. configure script have stripped off my 
>>>> compiler flags after '-tp',
>>>> when passing it to libtool in link mode? [Somehow it works in 1.4.3.]
>>>> Is there any workaround or patch?
>>>> 
>>>> 
>>>> Many thanks,
>>>> Gus Correa
>>>> 
>>>> ******
>>>> 
>>>> More details:
>>>> CentOS Linux 5.2 x86_64, libtool 1.5.22, PGI 11.7.
>>>> 
>>>> Configure parameters:
>>>> export CC=pgcc
>>>> export CXX=pgcpp
>>>> export F77='pgfortran'
>>>> export FC=${F77}
>>>> 
>>>> export CFLAGS='-tp shanghai-64 -fast -Mfprelaxed'
>>>> export CXXFLAGS=${CFLAGS}
>>>> export FFLAGS=${CFLAGS}
>>>> export FCFLAGS=${FFLAGS}
>>>> 
>>>> ../configure \
>>>> --prefix=${MYINSTALLDIR} \
>>>> --with-libnuma=/usr \
>>>> --with-tm=/opt/torque/2.4.11/gnu-4.1.2 \
>>>> --with-openib=/usr \
>>>> --enable-static \
>>>> 2>&1 | tee configure_${build_id}.log
>>>> 
>>>> ****
>>>> 
>>>> #################### ERROR MESSAGE ###########################
>>>> 
>>>> libtool: compile:  pgcc -DHAVE_CONFIG_H -I. 
>>>> -I../../../../../opal/mca/memory/ptmalloc2 -I../../../../opal/include 
>>>> -I../../../../orte/include -I../../../../ompi/include 
>>>> -I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -DMALLOC_DEBUG=0 
>>>> -D_GNU_SOURCE=1 -DUSE_TSD_DATA_HACK=1 -DMALLOC_HOOKS=1 
>>>> -I../../../../../opal/mca/memory/ptmalloc2/sysdeps/pthread 
>>>> -I../../../../../opal/mca/memory/ptmalloc2/sysdeps/generic 
>>>> -I../../../../.. -I../../../.. -I../../../../../opal/include 
>>>> -I../../../../../orte/include -I../../../../../ompi/include -D_REENTRANT 
>>>> -DNDEBUG -tp shanghai-64 -fast -Mfprelaxed -c 
>>>> ../../../../../opal/mca/memory/ptmalloc2/dummy.c -o dummy.o >/dev/null 2>&1
>>>> /bin/sh ../../../../libtool --tag=CC   --mode=link pgcc  -DNDEBUG -tp 
>>>> shanghai-64 -fast -Mfprelaxed   -export-dynamic   -o libopenmpi_malloc.la 
>>>> -rpath /home/sw/openmpi/1.4.4/pgi-11.7/lib dummy.lo  -lnsl -lutil  
>>>> libtool: link: pgcc -shared  -fpic -DPIC  .libs/dummy.o   -lnsl -lutil -lc 
>>>>  -tp   -Wl,-soname -Wl,libopenmpi_malloc.so.0 -o 
>>>> .libs/libopenmpi_malloc.so.0.0.0
>>>> pgcc-Fatal-Switch -tp must have a value
>>>> -tp=amd64|amd64e|athlon|athlonxp|barcelona|barcelona-32|barcelona-64|core2|core2-32|core2-64|istanbul|istanbul-32|istanbul-64|k7|k8|k8-32|k8-64|k8-64e|nehalem|nehalem-32|nehalem-64|p5|p6|p7|p7-32|p7-64|penryn|penryn-32|penryn-64|piii|piv|px|px-32|px-64|sandybridge|sandybridge-32|sandybridge-64|shanghai|shanghai-32|shanghai-64|x64
>>>>                 Choose target processor type
>>>> amd64           Same as -tp k8-64
>>>> amd64e          Same as -tp k8-64e
>>>> athlon          AMD 32-bit Athlon Processor
>>>> athlonxp        AMD 32-bit Athlon XP Processor
>>>> barcelona       AMD Barcelona processor
>>>> barcelona-32    AMD Barcelona processor, 32-bit mode
>>>> barcelona-64    AMD Barcelona processor, 64-bit mode
>>>> core2           Intel Core-2 Architecture
>>>> core2-32        Intel Core-2 Architecture, 32-bit mode
>>>> core2-64        Intel Core-2 Architecture, 64-bit mode
>>>> istanbul        AMD Istanbul processor
>>>> istanbul-32     AMD Istanbul processor, 32-bit mode
>>>> istanbul-64     AMD Istanbul processor, 64-bit mode
>>>> k7              AMD Athlon Processor
>>>> k8              AMD64 Processor
>>>> k8-32           AMD64 Processor 32-bit mode
>>>> k8-64           AMD64 Processor 64-bit mode
>>>> k8-64e          AMD64 Processor rev E or later, 64-bit mode
>>>> nehalem         Intel Nehalem processor
>>>> nehalem-32      Intel Nehalem processor, 32-bit mode
>>>> nehalem-64      Intel Nehalem processor, 64-bit mode
>>>> p5              Intel P5 Pentium Architecture
>>>> p6              Intel P6 Architecture (Pentium Pro, II, III)
>>>> p7              Intel P7 Architecture (Pentium 4, Xeon, Centrino)
>>>> p7-32           Intel P7 Architecture (Pentium 4, Xeon, Centrino)
>>>> p7-64           Intel P7 Architecture with EM64T, 64-bit mode
>>>> penryn          Intel Penryn Architecture
>>>> penryn-32       Intel Penryn Architecture, 32-bit mode
>>>> penryn-64       Intel Penryn Architecture, 64-bit mode
>>>> piii            Intel Pentium III
>>>> piv             Intel Pentium 4
>>>> px              Generic x86 Processor
>>>> px-32           Generic x86 Processor, 32-bit mode
>>>> px-64           Generic x86-64 architecture
>>>> sandybridge     Intel SandyBridge processor
>>>> sandybridge-32  Intel SandyBridge processor, 32-bit mode
>>>> sandybridge-64  Intel SandyBridge processor, 64-bit mode
>>>> shanghai        AMD Shanghai processor
>>>> shanghai-32     AMD Shanghai processor, 32-bit mode
>>>> shanghai-64     AMD Shanghai processor, 64-bit mode
>>>> x64             Unified AMD/Intel 64-bit mode
>>>> make[2]: *** [libopenmpi_malloc.la] Error 2
>>>> make[2]: Leaving directory 
>>>> `/home/swinst/openmpi/1.4.4/openmpi-1.4.4/build_pgi-11.7/opal/mca/memory/ptmalloc2'
>>>> make[1]: *** [all-recursive] Error 1
>>>> make[1]: Leaving directory 
>>>> `/home/swinst/openmpi/1.4.4/openmpi-1.4.4/build_pgi-11.7/opal'
>>>> make: *** [all-recursive] Error 1
>>>> 
>>>> 
>>>> _______________________________________________
>>>> users mailing list
>>>> us...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> users mailing list
>>> us...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>> 
>> 
>> _______________________________________________
>> users mailing list
>> us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users


Reply via email to