On Jan 19, 2005, at 12:04 PM, Ralf Wildenhues wrote:
>>>> Most likely, the problem occurs earlier. During compile, >libtool
>>>> munges
>>>> the -xarch=amd64. Can you confirm this by looking at what >libtool
>>>> calls
>>>> when the sources to liblam.la are compiled?
>
> ..this failure is a LAM bug. Minimal, untested patch below.
Ah ha!
Your patch is right on -- I neglected to take into account that flags
may include "=". Mea culpa. Will be fixed in 7.1.2 (I'll commit to
SVN shortly; this will appear in tonight's nightly snapshot tarball).
> I should note that the way of getting at flags by grepping Makefiles is
> quite brittle and could be subject to all sorts of interesting
> failures.
> E.g., configure could output
> LIBS = -la \
> -lb
> or make use of other variables or whatever. None of this is specified
> by Automake. (One could replace `egrep | cut' with a little sed
> hackery to prepare for the first issue.)
Yeah, unfortunately, we're aware of this, but this hack was the only
reasonable way that we could think of to extract the information that
we needed without adding undue complexity and overhead for what, in
this case, was a simple, single-line result.
However, it's not quite as icky as it looks.
Remember that the values of LDFLAGS and LIBS are passed in via
AC_SUBST. Automake does not re-indent these values to span lines
(there's no good technical reason to, and a lot of technical complexity
involved in doing it safely). So we ruled it "safe enough" to assume
that LDFLAGS and LIBS would always be a single line in the resulting
Makefiles.
> Furthermore, there are a couple more such places where I'm not sure a
> similar thing could happen. However, I don't know LAM well enough to
> be able to decide.
Can you pass those along to me?
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
