On Wed, Aug 5, 2020 at 9:41 PM Christoph Junghans <junghans(a)votca.org> wrote:
On Wed, Aug 5, 2020 at 12:54 PM Jeff Law <law(a)redhat.com> wrote:
>
> On Wed, 2020-08-05 at 12:45 -0600, Christoph Junghans wrote:
> > Hi,
> >
> > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > when doing this I hit
> >
https://github.com/espressomd/espresso/issues/3396, which prevents us
> > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > which works for the build with openmpi, but gets ignored for the mpich
> > build.
> >
> > I think the problem is that CMake picks up the lto flags from mpicxx
> > and then puts them in
> > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> >
> > So I think the fix would be to strip these flags from mpicc. Sounds
reasonable?
> >
> > The flags also contain
> > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > while back:
https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> You might try %global (which has global scope) rather than %define (which has a
> local scope). Or just strip it away like you've proposed.
%global doesn't help either.
I think there have been similar problems with, for example, python and
ruby extensions.
python / ruby will store the CFLAGS they were built with and use them
to build binary extensions, which breaks when they contain e.g. the
flags for specs from redhat-rpm-config.
The mpich case sounds really similar. You'll probably need to adapt
that build environment to drop some flags which don't make sense in
the MPI context.
Fabio