On Jun 10, 2015, at 12:00 AM, Gilles Gouaillardet <gil...@rist.or.jp> wrote: > > that can happen indeed, in a complex but legitimate environment : > > mkdir ~/src > cd ~/src > tar xvfj openmpi-1.8.tar.bz2 > mkdir ~/build/openmpi-v1.8 > cd ~/build/openmpi-v1.8 > ~/src/openmpi-1.8/configure > make > > then a few days later > > cd ~/src > tar xvfj openmpi-v1.8.5-46-g9f5f498.tar.bz2 > # use the *same* build directory > cd ~/build/openmpi-v1.8 > # > (~/src/openmpi-v1.8.5-46-g95f5f498/opal/include/opal/opal_portable_platform.h > # must be more recent than > ~/src/openmpi-1.8/ompi/include/mpi_portable_platform.h > # just touch > ~/src/openmpi-v1.8.5-46-g95f5f498/opal/include/opal/opal_portable_platform.h > # to force the issue > ~/src/openmpi-v1.8.5-46-g9f5f498/configure > make => BOUM
Mmmm. Interesting. Ok, good to know! That means that the fix I committed should, indeed, fix this scenario (see https://github.com/open-mpi/ompi/commit/fbaf6888f8905acc428d9a26eab9983f378d9326). > i just found an other issue with this scenario : > symlinks in the profile directories (ompi/mpi/c/profile, > ompi/mpi/fortran/mpif-h/profile, oshmem/shmem/c/profile) are not recreated > and points to the previous source tree. > (that caused one crash at least, and likely silently compiles old sources > most of the time) Mmmm... yes, I guess you're right; that could lead to super-subtle bugs. I guess I should add the "rm" to those sym link rules, too. Good catch! -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
