Thanks for the report. I don't know much about OSHMEM, but I'm guessing the files were laid out that way for a reason (e.g., maybe the OSHMEM spec calls for both of those files to exist?).
I've filed an issue here to track it: https://github.com/open-mpi/ompi/issues/1868 Additionally, have you reported this issue upstream to cmake? It seems like this is actually a bug in cmake and should be fixed. > On Jul 13, 2016, at 7:30 AM, Paul Kapinos <kapi...@itc.rwth-aachen.de> wrote: > > Hi Gilles, > > On 07/13/16 01:10, Gilles Gouaillardet wrote: >> Paul, >> >> The two header files in include/mpp simply include the file with the same >> name >> in the upper directory. > > Yessir! > (and CMake do not care about the upper directory and build infinite loop) > > >> 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 ? > > It work very well, at least for the one test case provided. So yes, patching > any installation of Open MPI could be a workaround. However we would really > love to avoid this need to patch any Open MPI installation > > Maybe OpenMPI's developer could think about how-to minimize the probability > of such loops? Symlink is one alternative, another one would be renaming one > of the headers.. > we fully trust to Open MPI's developers expertise in this :-) > > Have a nice day, > > Paul Kapinos > > > pk224850@linuxc2:/opt/MPI/openmpi-1.8.1/linux/intel/include[519]$ ls -la > mpp/shmem.fh > lrwxrwxrwx 1 pk224850 pk224850 11 Jul 13 13:20 mpp/shmem.fh -> ../shmem.fh > >> >> Cheers, >> >> Gilles >> >> On Wednesday, July 13, 2016, Paul Kapinos <kapi...@itc.rwth-aachen.de >> <mailto: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 >> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2016/07/19195.php >> > > > -- > Dipl.-Inform. Paul Kapinos - High Performance Computing, > RWTH Aachen University, IT Center > Seffenter Weg 23, D 52074 Aachen (Germany) > Tel: +49 241/80-24915 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/07/19196.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/