Paul,
The two header files in include/mpp simply include the file with the same
name in the upper directory.
A simple workaround is to replace these two files in include/mpp with
symbolic links to files with the same name in the upper directory.
Would you mind giving this a try ?
Cheers,
Gilles
On Wednesday, July 13, 2016, Paul Kapinos <kapi...@itc.rwth-aachen.de>
wrote:
> Dear OpenMPI developer,
>
> we have some troubles when using OpenMPI and CMake on codes using 'SHMEM'.
>
> Cf. 'man shmem_swap',
> > Fortran:
> > INCLUDE "mpp/shmem.fh"
>
> Yes here is one such header file:
> > openmpi-1.X.Y/oshmem/include/mpp/shmem.fh
> ... since version 1.7. at least.
>
>
> The significnat content is this line:
> > include 'shmem.fh'
> whereby OpenMPI mean to include not the same file by itself (= infinite
> loop!) but I believe these one file:
> > openmpi-1.X.Y/oshmem/include/shmem.fh
>
> (The above paths are in the source code distributions; in the installation
> the files are located here: include/shmem.fh include/mpp/shmem.fh)
>
>
> This works. Unless you start using CMake. Because CMake is 'intelligent'
> and try to add the search paths recursively, (I believe,) gloriously
> enabling the infinite loop by including the 'shmem.fh' file from the
> 'shmem.fh' file.
>
> Steps to repriduce:
> $ mkdir build; cd build; cmake ..
> $ make
>
> The second one command need some minute(s), sticking by the 'Scanning
> dependencies of target mpihelloworld' step.
>
> If connecting by 'strace -p <PID>' to the 'cmake' process you will see
> lines like below, again and again. So I think CMake just include the
> 'shmem.fh' file from itself unless the stack is full / a limit is reached /
> the moon shines, and thus hangs for a while (seconds/minutes) in the
> 'Scanning dependencies...' state.
>
> *Well, maybe having a file including the same file is not that good?*
> If the file 'include/mpp/shmem.fh' would include not 'shmem.fh' but
> 'somethingelse.fh' located in 'include/...' these infinite loop would be
> impossible at all...
>
> And by the way: is here a way to limit the maximum include depths in CMake
> for header files? This would workaround this one 'infinite include loop'
> issue...
>
> Have a nice day,
>
> Paul Kapinos
>
> ..............
> access("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
> R_OK) = 0
> stat("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
> {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
> open("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
> O_RDONLY) = 5271
> fstat(5271, {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
> mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0x7f08457d2000
> read(5271, "!\n! Copyright (c) 2013 Me"..., 32768) = 205
> read(5271, "", 32768) = 0
>
> access("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
> R_OK) = 0
> stat("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
> {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
> open("/opt/MPI/openmpi-1.10.2/linux/intel_16.0.2.181/include/mpp/shmem.fh",
> O_RDONLY) = 5272
> fstat(5272, {st_mode=S_IFREG|0644, st_size=205, ...}) = 0
> mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0x7f08457ca000
> read(5272, "!\n! Copyright (c) 2013 Me"..., 32768) = 205
> read(5272, "", 32768) = 0
> ..............
>
> --
> Dipl.-Inform. Paul Kapinos - High Performance Computing,
> RWTH Aachen University, IT Center
> Seffenter Weg 23, D 52074 Aachen (Germany)
> Tel: +49 241/80-24915
>
