OK, this is getting downright bizarre. My guess was that it was the
explicit act of setting PREFIX that was breaking the install, so I
tried a second installation with no prefix command, expecting it to
install into /usr/local.
autoconf didn't want to forget about the old installation
(/usr/local/lam-7.1.1)
It found lamclean and went for the old directory, so everything worked
fine. So I uninstalled the working version, and then tried again.
This time it said at the top of the configure output that it was going
to install into /usr/local, and in the end broke the C++ example
compilation with the same error message as before. Doing a mpic++
--showme gave:
WARNING: mpic++ expected to find liblammpio.* in
/usr/local/lam-7.1.1/lib
WARNING: MPI-2 IO support will be disabled
WARNING: mpic++ expected to find liblammpi++.* in
/usr/local/lam-7.1.1/lib
WARNING: MPI C++ support will be disabled
xlc++ -I/usr/local/lam-7.1.1/include -D_REENTRANT
-L/usr/local/lam-7.1.1/lib -lmpi -llam -ldl
Note the reappearance of the /usr/local/lam-7.1.1 directory! It just
won't give up.
Tried again with an actual prefix of /usr/local.
This time it installed happily into /usr/local, but again the old
directory has some life:
starone:~/Applications/testlam/lam-7.1.1$ which mpic++
/usr/local/bin/mpic++
starone:~/Applications/testlam/lam-7.1.1$ mpic++ --showme
xlc++ -I/usr/local/lam-7.1.1/include -D_REENTRANT
-L/usr/local/lam-7.1.1/lib -llammpio -llammpi++ -lmpi -llam -ldl
And this time the C++ examples compile fine. Note that the theory that
setting the prefix explicitly does indeed make it execute cleanly is
working out.
Last attempt. I'm going to uninstall both, and then nuke the damn
/usr/local/lam-7.1.1 directory before trying one last time with no
prefix.
It did it again. This time there was no such directory, never mind no
suggestions to use it:
WARNING: mpic++ expected to find liblammpio.* in
/usr/local/lam-7.1.1/lib
WARNING: MPI-2 IO support will be disabled
WARNING: mpic++ expected to find liblammpi++.* in
/usr/local/lam-7.1.1/lib
WARNING: MPI C++ support will be disabled
xlc++ -I/usr/local/lam-7.1.1/include -D_REENTRANT
-L/usr/local/lam-7.1.1/lib -lmpi -llam -ldl
starone:~/Applications/testlam/lam-7.1.1$ ls /usr/local/lam-7.1.1
ls: /usr/local/lam-7.1.1: No such file or directory
starone:~/Applications/testlam/lam-7.1.1$ ls /usr/local
bin etc include info lib man share teTeX
starone:~/Applications/testlam/lam-7.1.1$ grep "/usr/local/lam-7.1.1"
config.log
PATH: /usr/local/lam-7.1.1/bin
The only existence it had was in the PATH environment variable. mpicc
had a similar problem, but one that seemed to have softer consequences:
starone:~/Applications/testlam/lam-7.1.1$ mpicc --showme
WARNING: mpicc expected to find liblammpio.* in /usr/local/lam-7.1.1/lib
WARNING: MPI-2 IO support will be disabled
xlc -I/usr/local/lam-7.1.1/include -D_REENTRANT
-L/usr/local/lam-7.1.1/lib -lmpi -llam -ldl
At this point, I shall delete this test directory after doing an
uninstall, reinstall my "good" version, and back away slowly, careful
to make no sudden movements.
Joe
On 16/10/2004, at 11:03 PM, Jeff Squyres wrote:
> On Oct 16, 2004, at 1:01 AM, Joseph Hope wrote:
>
>> No worries. I tried an example with -I/usr/local/include as
>> suggested,
>> and it compiled fine. Another good theory is that the real problem is
>> some sort of conflict with something else in /usr/local, but I tried
>> installing lam before anything else, and even now /usr/local is
>> practically empty. I've seen this bug appear elsewhere on this list,
>> so
>> they may have other ideas.
>
> Odd. I can't think of another reason why this would fail. A few more
> thoughts:
>
> 1. If you have the time, try another installation of LAM with the
> prefix of /usr/local and try compiling manually -- i.e., not with
> mpicc. Use "mpicc -showme" to see what LAM would have executed and
> then do that manually. The results should be identical, of course,
> but at least you now have a fine-grained mechanism that you can add /
> remove flags on the command line to see what actual the problem is.
>
> 2. I can't imagine that this is the problem, but it's worth a shot: in
> your "good" copy of LAM, try adding -L/usr/local and see if that
> causes it to fail. -L should have nothing to do with the compilation
> phase, but it should be the only other flag that contains
> "/usr/local", so we might as well test it. Stranger things have
> happened in the past. :-)
>
> 3. Compare the output of a compile from your "good" and "bad"
> installations of LAM through the preprocessor (I'm assuming "-E" is
> the flag for that). There must be some kind of difference -- can you
> send what the differences are?
>
> #3 is probably going to be the most revealing.
>
>> Given my recent experiences with my own cross-platform package
>> (www.xmds.org), for which I wanted LAM-MPI in the first place, my
>> first
>> guess is that this is an autoconf bug. I'd look for anything that is
>> even
>> slightly different if 'prefix' is set manually than if it defaults to
>> /usr/local.
>>
>> A year a go, I typed 'I hate autoconf' into Google, and discovered
>> that
>> there were T-shirts!
>
> LOL!
>
> I'm kinda doubting that this is an autoconf bug; it *shouldn't* be
> related to what we have autoconf doing. But then again, never say
> "never"...
>
> To shed a little light on our philosophy...
>
> Autoconf is "the best of the worst". It's pretty painful at times,
> but there's really nothing better (in our humble opinion). :-\
>
> Automake, on the other hand, is pretty great. It's a little rough
> around the edges (and periodically has some annoying bugs), but as
> long as you're going to use "make" (and all of its shortcomings),
> Automake is one fine tool. Where else can you write a 5 line
> Makefile.am and have it blown up into a 100k Makefile? ;-)
>
> Libtool is also pretty nice, and has only been getting better in the
> past 2-3 years. It's always a struggle for Libtool to keep up with
> all the vendor compilers out there (and sometimes that causes problems
> for us), but it's a *far* better solution (for us) than hand-coding
> all that stuff for building [shared] libraries. And its integration
> into Automake is great (in our humble opinion).
>
> So this was a little off-topic, but I wanted to share the reasons why
> we use these three tools in LAM (and we use them in Open MPI as well).
>
> --
> {+} Jeff Squyres
> {+} jsquyres_at_[hidden]
> {+} http://www.lam-mpi.org/
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
|
