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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
