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/
|
