This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Feb 20, 2008, at 9:45 AM, Ben Allan wrote:
>> Our assumption was that if some other package defined these values,
>> would either likely be coming from the same standard autoconf tests
>> use the same #define conventions as the autoconf tests. As such, the
>> values that they are #defined to would be the same (and compilers
>> whine about multiple #defines of the same macro to the same value
>> -- they
>> only whine if the values are different).
> The particular offending packages in question are indeed using
> autoconf/autoheader, however ompi's defines
> #define HAVE_LONG_LONG 1
> while the others only
> #define HAVE_LONG_LONG
> more ac version madness?
Gaa! Yes, this could definitely be the case. :-(
>> There's two places that would need to be changed:
>> - the relevant parts of OMPI's configure script to *also* define an
>> OMPI_* equivalent of the macro (which will sometimes mean extracting
>> non-public information from the Autoconf tests -- usually a risky
>> proposition because Autoconf can change their internals at any time).
>> The only safe way I can think of would be to AC_TRY_RUN and write the
>> #define'd value out to a temp file. This, of course, won't work for
>> cross-compiling environments, though.
>> - modify mpi.h.in to use the new OMPI_* macros.
>> Keep in mind that mpi.h only has a small subset of the #defines from
>> OMPI's configure script. opal_config.h (and internal OMPI file
>> that is
>> not installed) has *all* the #defines; that's what's used to
>> compile the
>> OMPI code base. mpi.h replicates a small number of these defines
>> are used by OMPI's public interface.
> I will think about this guidance and see what kind of patches and
> alternative patches I can suggest.
> I did not detect autoheader being used in the process of building
> mpi.h; is that correct? it would make some simpler workarounds easier.
Correct. We have mpi.h.in in the SVN repository -- it is *not*
automatically generated. We just put the #undef HAVE_LONG_LONG (etc.)
lines in there (which is the same format that autoheader generates),
and config.status will morph these into #define... as relevant.
While I agree that having AC actually define them to a value is a Good
Thing (better than just defining it to be empty), I do see the pickle
that it has put us in. :-\ I don't see an obvious solution.