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:
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).
|
