[gmx-users] building GROMACS 4.5.4 on Power6 with CMAKE

[Szilárd Páll]

Hi,

I have not followed the entire discussion so I might be completely
wrong, I might be fill in some gaps.

> Firstly, including config.h inside the fortran .F kernel files for power6 is
> causing problems with
> their parsing using xlf. adding -WF,-qfpp didn't help. Had to provide a
> modified xlf.cfg config file
> for XLF (cppoptions = -P, instead of -C)
> and pass it on with -F option and then add -qarch=pwr6 (all passed manually)
> for compilation of
> each power6 kernel .F file. That fixed the problem with the compilation of
> Power6 kernels part.
>
> Is there any more handy way of doing that? I've noticed that upon using
> Power6, cmake generates
> Fortran_DEFINES and Fortran_FLAGS inside
> src/gmxlib/CMakeFiles/gmx.dir/flags.make file.
> They somehow can not be modified from the command line. Same goes for the
> preprocessor flags.
> (-DCMAKE_CPP_FLAGS do not work?).

If you want to pass *global* flags to the the C++ compiler you can do
that through CMAKE_CXX_FLAGS variable (note: CXX not CPP!). However,
if you happen to need flags only for certain files or internal
libraries, it's slightly more tricky; it requires the file/target
property COMPILE_FLAGS to be modified fron inside the CMake scripts.

> Secondly, now I get something else:
> Linking C shared library libmd.so
> xlc: 1501-218 (W) file ../gmxlib/libgmx.so.6 contains an incorrect file
> suffix
> ../gmxlib/libgmx.so.6: In function `__bss_start':
> (*ABS*+0x1025cb00): multiple definition of `_edata'
> ../gmxlib/libgmx.so.6: In function `__data_start':
> (.data+0x8): multiple definition of `__dso_handle'
> /usr/lib64/gcc/powerpc64-suse-linux/4.3/crtbeginS.o:(.data.rel+0x0): first
> defined here
> ../gmxlib/libgmx.so.6: In function `_fini':
> (.opd+0x30): multiple definition of `_fini'
> /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/crti.o:initfini.c:(.opd+0x18):
> first defined here
> ../gmxlib/libgmx.so.6: In function `_init':
> (.opd+0x18): multiple definition of `_init'
> /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/crti.o:initfini.c:(.opd+0x0):
> first defined here
> ../gmxlib/libgmx.so.6: In function `_end':
> (*ABS*+0x10268b20): multiple definition of `_end'
> ../gmxlib/libgmx.so.6: In function `__bss_start':
> (*ABS*+0x1025cb00): multiple definition of `__bss_start'
> /usr/lib64/gcc/powerpc64-suse-linux/4.3/crtendS.o:(.dtors+0x0): multiple
> definition of `__DTOR_END__'
> ../gmxlib/libgmx.so.6:(.dtors+0x8): first defined here
> /usr/bin/ld: error in ../gmxlib/libgmx.so.6(.eh_frame); no .eh_frame_hdr
> table will be created.
> make[2]: *** [src/mdlib/libmd.so.6] Error 1
> make[1]: *** [src/mdlib/CMakeFiles/md.dir/all] Error 2
> make: *** [all] Error 2

That unfortunately looks like a nasty symbol multiple definition
issue. My guess is that the symbols xlc is complaining about are
defined in libgmx.so.6 and when the linker tries to do the final
linking stage it ends up choking due to conflicts with symbols is some
library where the respective symbols are defined (or in fact originate
from).

AFAIK this could happen when one provides a linker option
"-lsomething" to a compile-only command iso a [compile+] link command:
$ g++ -c foo.cpp -o foo.o -lbar
$ g++ foo.o -o foobar

Let me know if this makes sense, you could look at the verbose make
output (make VERBOSE=1) and maybe you notice something like this.

Cheers,
--
Szilárd

> cheers,
> --
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use the www interface
> or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>