Ok, that pretty much confirms what I suspected. But I'm still curious
as to why when you compiled manually with xlc++ (not mpic++) and added
-I/usr/local, it didn't fail. That seems to defy explanation. :-\
I'll try to scrounge up a mac around here with the xlc compilers; I
think we have some that are soon-to-be-deployed in my lab (in a week or
three...?).
On Oct 19, 2004, at 12:58 AM, Joseph Hope wrote:
> Jeff,
>
> I checked "which mpic++", have no LAMHOME, got my test directory from
> the tarball. So, the old directory _must_ have been found from
> previous 'make' cruft. Just tested this, and it's true, so one
> mystery solved, and the original problem remains. I went through the
> whole process again to produce the cleanest possible version of the
> original error:
>
> Installed from tarball, having nuked by hand all traces of lam from
> all /usr/local directories. This finally forgot about
> /usr/local/lam-7.1.1 and compiled OK, but had the old C++ error:
>
> Install options:
>
> ./configure --without-romio --without-profiling --without-fc
> --with-debug --disable-tv --disable-tv-queue
> --with-memory-manager=none --with-rsh="/usr/bin/ssh -x" CC=xlc
> CFLAGS='' CXX=xlc++ CXXFLAGS=''
>
> starone:~/Applications/testlam/lam-7.1.1$ mpic++ --showme
> xlc++ -I/usr/local/include -D_REENTRANT -L/usr/local/lib -llammpi++
> -lmpi -llam -ldl
> starone:~/Applications/testlam/lam-7.1.1$ which mpic++
> /usr/local/bin/mpic++
> starone:~/Applications/testlam/lam-7.1.1$ cd examples/cxx
> starone:~/Applications/testlam/lam-7.1.1/examples/cxx$ make
> source='chapter_10_mpi2.cc' object='chapter_10_mpi2.o' libtool=no \
> depfile='.deps/chapter_10_mpi2.Po'
> tmpdepfile='.deps/chapter_10_mpi2.TPo' \
> depmode=none /bin/sh ../.././config/depcomp \
> mpic++ -g -c -o chapter_10_mpi2.o chapter_10_mpi2.cc
> "/usr/local/include/mpi2cxx/mpi2cxx_map.h", line 26.7: 1540-0121 (S) A
> template cannot have "C" linkage.
> "/usr/local/include/mpi2cxx/functions.h", line 59.1: 1540-1172 (S)
> More than one function "Init" has non-C++ linkage.
> [...extra errors deleted]
>
>
> configure/make outputs attached:
> <installoutputs.tar.gz>
>
>
> The result was exactly the same when I used (clean start again):
>
> ./configure --prefix=/usr/local --without-romio --without-profiling
> --without-fc --with-debug --disable-tv --disable-tv-queue
> --with-memory-manager=none --with-rsh="/usr/bin/ssh -x" CC=xlc
> CFLAGS='' CXX=xlc++ CXXFLAGS=''
>
> This means that is indeed /usr/local that is the problem, and not the
> act of manually setting the prefix.
>
> More than that, I cannot help. I shall now retire to my working
> version. Good luck :)
>
> Joe
>
>
>
>
> On 18/10/2004, at 5:47 PM, Jeff Squyres wrote:
>
>> Indeed, this is quite bizarre. I can think of a few reasons why the
>> 7.1.1 dir kept showing up (pardon if some of these are mundane -- I
>> have to ask):
>>
>> - are you sure what you were executing the "right" mpic++? i.e.,
>> what does "which mpic++" tell you? Can you try executing the mpic++
>> in tools/wrappers, just to be absolutely 100% sure that you're
>> running the right one?
>>
>> - do you have the LAMHOME environment variable set? If so, unset it
>> (it definitely affects the outcome of running the wrapper compilers).
>>
>> - double check that the wrapper compilers are compiled properly -- do
>> any one or more of the following:
>>
>> - remove your LAM 7.1 source tree and un-tar it from a tarball
>> - "make clean" in the source tree before re-running "make all
>> install" (can be before or after re-running ./configure, but you must
>> have had to have run configure at least once)
>> - ensure that the wrappers are recompiled after you re-run
>> configure; e.g., "cd tools/wrappers; make clean all"
>>
>> - you can verify which directory is built into the wrappers two ways:
>>
>> - run laminfo; the prefix dir is shown at the top of the output
>> - look at the individual compilation lines when the wrappers are
>> compiled; the default prefix, libdir, and incdir are all passed in on
>> the command line via -D flags.
>>
>> -----
>>
>> If you have time for these tests (and I thank you for your continued
>> patience!), the following configure flags may speed things up a bit
>> for testing porpoises:
>>
>> --without-romio --without-profiling --without-fc --with-debug
>>
>> The effects of the wrappers in terms of the -I and -L flags that it
>> passes will be the same with and without these flags (note that they
>> won't look for liblammpio anymore, since that's the ROMIO library).
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
