On Wed, Aug 5, 2020 at 9:41 PM Christoph Junghans <junghans@xxxxxxxxx> wrote: > > On Wed, Aug 5, 2020 at 12:54 PM Jeff Law <law@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
