Re: [OMPI devel] v1.8 - compile/dist problem

2014-07-25 Thread Peter Breitenlohner

On Thu, 24 Jul 2014, Bert Wesarg wrote:


On 07/24/2014 02:52 PM, Peter Breitenlohner wrote:



This typically occurs when you try to create a file (symlink) in a
nonexistent directory.  In such situations the make rules must ensure that
such directories exist, e.g., via

some_target: Some_prerequisite
 $(MKDIR_P) hooks
 $(LN_S) $(srcdir)/hooks/vt_unify_hooks_base.cc
hooks/vt_unify_hooks_base.cc


But the dep rules should already ensure this, as it creates the .deps 
directory at the end of configure. Though if this is not guaranteed to happen 
(maybe it depends on the used compiler) than we would need to ensure it in 
the makefile itself.


perhaps true, and I actually don't know where the 'ln -s' comes from.


Does someone know the details from autoconf about this?


at least part of the problem comes from the Automake option 'subdir-objects'
together with the *_SOURCES defined in Makefile.common in the directories
  openmpi-1.8.1/ompi/contrib/vt/vt/tools/{vtunify,vtfilter}/
defining source files as, e.g.,
  $(VTUNIFYSRCDIR)/hooks/vt_unify_hooks_aevents.cc
together with
  VTUNIFYSRCDIR = $(srcdir)

It was never required (nor recommended) to specify explicitly that sources
are in the source tree, Automake-generated rules always try to find the file
first in the build tree and then in the source tree.

Together with 'subdir-objects' and Automake 1.14.1 this has disastrous effects:
  foo_SOURCES = foo.c ${srcdir}/sub/foosub.c
creates the dependency file
  '${srcdir}'/sub/.deps/foosub.Po
in the build tree but needs
  ${srcdir}/sub/.deps/foosub.Po
and therefore fails. SIMILARLY
  foo_SOURCES = foo.c $(srcdir)/sub/foosub.c
creates
  '$(srcdir)'/sub/.deps/foosub.Po
but needs
  $(srcdir)/sub/.deps/foosub.Po
and fails. Finally
  foo_SOURCES = foo.c @srcdir@/sub/foosub.c
tries to create
  sub/foosub.o
  sub/.deps 
and succeeds if the source tree is writable but 'make distcheck' with its

read-only source tree fails as demonstrated by the attached tiny tarball.

Part of all that is due to a bug in Automake 1.14.1 that will probably be
fixed in 1.14.2, but one should certainly not say explicitly that source
files are in the source tree.

Regards
Peter

foo-1.0.tar.gz
Description: Binary data


Re: [OMPI devel] v1.8 - compile/dist problem

2014-07-25 Thread Bert Wesarg

On 07/25/2014 11:51 AM, Peter Breitenlohner wrote:

On Thu, 24 Jul 2014, Bert Wesarg wrote:


On 07/24/2014 02:52 PM, Peter Breitenlohner wrote:



This typically occurs when you try to create a file (symlink) in a
nonexistent directory.  In such situations the make rules must ensure
that
such directories exist, e.g., via

some_target: Some_prerequisite
 $(MKDIR_P) hooks
 $(LN_S) $(srcdir)/hooks/vt_unify_hooks_base.cc
hooks/vt_unify_hooks_base.cc


But the dep rules should already ensure this, as it creates the .deps
directory at the end of configure. Though if this is not guaranteed to
happen (maybe it depends on the used compiler) than we would need to
ensure it in the makefile itself.


perhaps true, and I actually don't know where the 'ln -s' comes from.


Does someone know the details from autoconf about this?


at least part of the problem comes from the Automake option
'subdir-objects'
together with the *_SOURCES defined in Makefile.common in the directories
   openmpi-1.8.1/ompi/contrib/vt/vt/tools/{vtunify,vtfilter}/
defining source files as, e.g.,
   $(VTUNIFYSRCDIR)/hooks/vt_unify_hooks_aevents.cc
together with
   VTUNIFYSRCDIR = $(srcdir)

It was never required (nor recommended) to specify explicitly that sources
are in the source tree, Automake-generated rules always try to find the
file
first in the build tree and then in the source tree.

Together with 'subdir-objects' and Automake 1.14.1 this has disastrous
effects:
   foo_SOURCES = foo.c ${srcdir}/sub/foosub.c
creates the dependency file
   '${srcdir}'/sub/.deps/foosub.Po
in the build tree but needs
   ${srcdir}/sub/.deps/foosub.Po
and therefore fails. SIMILARLY
   foo_SOURCES = foo.c $(srcdir)/sub/foosub.c
creates
   '$(srcdir)'/sub/.deps/foosub.Po
but needs
   $(srcdir)/sub/.deps/foosub.Po
and fails. Finally
   foo_SOURCES = foo.c @srcdir@/sub/foosub.c
tries to create
   sub/foosub.o
   sub/.deps and succeeds if the source tree is writable but 'make
distcheck' with its
read-only source tree fails as demonstrated by the attached tiny tarball.

Part of all that is due to a bug in Automake 1.14.1 that will probably be
fixed in 1.14.2, but one should certainly not say explicitly that source
files are in the source tree.


Peter, I was the one who reported this bug to automake:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928

;-)

And this bug is /present since the beginning/. But where did you get the 
impression that this may get fixed in 1.14.2?


Anyway, this $(LN_S) is there to prevent having variable references in 
_SOURCES files, thus circumventing the subdir-objects bug in automake. 
We (in VT) are building some sources twice. Once with the $(CC) compiler 
and a second time with the $(MPICC) compiler. And for this we are now 
making symlinks in a new directory, so that it looks like they have the 
same paths for both builds.


Bert



Regards
Peter



--
Dipl.-Inf. Bert Wesarg
wiss. Mitarbeiter

Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH)
01062 Dresden
Tel.: +49 (351) 463-42451
Fax: +49 (351) 463-37773
E-Mail: bert.wes...@tu-dresden.de



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [OMPI devel] Trunk broken for --with-devel-headers?

2014-07-25 Thread Jeff Squyres (jsquyres)
I'm unable to replicate... perhaps you have a stale install tree?


On Jul 24, 2014, at 6:36 PM, Ralph Castain  wrote:

> Hey folks
> 
> Something in the last day or so appears to have broken the trunk's ability to 
> run --with-devel-headers. It looks like the headers are being installed 
> correctly, but mpicc fails to compile a program that uses them - the include 
> passes, but the linker fails:
> 
> Undefined symbols for architecture x86_64:
>   "_opal_hwloc172_hwloc_bitmap_alloc", referenced from:
>   _main in hello.o
>   "_opal_hwloc172_hwloc_bitmap_list_asprintf", referenced from:
>   _main in hello.o
>   "_opal_hwloc172_hwloc_get_cpubind", referenced from:
>   _main in hello.o
>   "_opal_hwloc_topology", referenced from:
>   _main in hello.o
>   "_orte_process_info", referenced from:
>   _main in hello.o
> ld: symbol(s) not found for architecture x86_64
> collect2: error: ld returned 1 exit status
> 
> Anybody else seeing this?
> Ralph
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15262.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [OMPI devel] Trunk broken for --with-devel-headers?

2014-07-25 Thread Ralph Castain
It seems to be only happening on my Mac, not Linux, but I'll try with a fresh 
checkout

On Jul 25, 2014, at 8:51 AM, Jeff Squyres (jsquyres)  wrote:

> I'm unable to replicate... perhaps you have a stale install tree?
> 
> 
> On Jul 24, 2014, at 6:36 PM, Ralph Castain  wrote:
> 
>> Hey folks
>> 
>> Something in the last day or so appears to have broken the trunk's ability 
>> to run --with-devel-headers. It looks like the headers are being installed 
>> correctly, but mpicc fails to compile a program that uses them - the include 
>> passes, but the linker fails:
>> 
>> Undefined symbols for architecture x86_64:
>>  "_opal_hwloc172_hwloc_bitmap_alloc", referenced from:
>>  _main in hello.o
>>  "_opal_hwloc172_hwloc_bitmap_list_asprintf", referenced from:
>>  _main in hello.o
>>  "_opal_hwloc172_hwloc_get_cpubind", referenced from:
>>  _main in hello.o
>>  "_opal_hwloc_topology", referenced from:
>>  _main in hello.o
>>  "_orte_process_info", referenced from:
>>  _main in hello.o
>> ld: symbol(s) not found for architecture x86_64
>> collect2: error: ld returned 1 exit status
>> 
>> Anybody else seeing this?
>> Ralph
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15262.php
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15265.php



[OMPI devel] Fwd: [OMPI users] missing link option for openmpi-1.8.2rc2 on Linux

2014-07-25 Thread Jeff Squyres (jsquyres)
OMPI developers --

Is "-z noexecstack" a linker option we should test for in configure, and use it 
if it works?

Are there any side effects that could cause problems?


Begin forwarded message:

> From: Siegmar Gross 
> Subject: [OMPI users] missing link option for openmpi-1.8.2rc2 on Linux
> Date: July 25, 2014 at 2:44:48 AM EDT
> To: 
> Reply-To: Siegmar Gross , Open MPI 
> Users 
> 
> Hi,
> 
> I installed openmpi-1.8.2rc2 on "openSUSE Linux 12.1 x86_64"
> with Sun C 5.12 and get the following warning if I run a small
> Java program. I get no warning for my gcc-4.9.0 version of
> openmpi-1.8.2rc2.
> 
> 
> linpc1 java 109 mpiexec -np 1 java InitFinalizeMain
> Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library
>  /usr/local/openmpi-1.8.2_64_cc/lib64/libmpi_java.so.1.2.0 which
>  might have disabled stack guard. The VM will try to fix the stack
>  guard now.
> It's highly recommended that you fix the library with
>  'execstack -c ', or link it with '-z noexecstack'.
> Hello!
> linpc1 java 110 
> 
> 
> I would be grateful if somebody can add the link option
> '-z noexecstack' to omit the warning. Thank you very much for
> your help in advance.
> 
> 
> Kind regards
> 
> Siegmar
> 
> ___
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post: 
> http://www.open-mpi.org/community/lists/users/2014/07/24871.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [OMPI devel] Fwd: [OMPI users] missing link option for openmpi-1.8.2rc2 on Linux

2014-07-25 Thread Ralph Castain
I think it's just libmpi_java that needs that linker flag, so it shouldn't 
affect anyone else

On Jul 25, 2014, at 8:59 AM, Jeff Squyres (jsquyres)  wrote:

> OMPI developers --
> 
> Is "-z noexecstack" a linker option we should test for in configure, and use 
> it if it works?
> 
> Are there any side effects that could cause problems?
> 
> 
> Begin forwarded message:
> 
>> From: Siegmar Gross 
>> Subject: [OMPI users] missing link option for openmpi-1.8.2rc2 on Linux
>> Date: July 25, 2014 at 2:44:48 AM EDT
>> To: 
>> Reply-To: Siegmar Gross , Open MPI 
>> Users 
>> 
>> Hi,
>> 
>> I installed openmpi-1.8.2rc2 on "openSUSE Linux 12.1 x86_64"
>> with Sun C 5.12 and get the following warning if I run a small
>> Java program. I get no warning for my gcc-4.9.0 version of
>> openmpi-1.8.2rc2.
>> 
>> 
>> linpc1 java 109 mpiexec -np 1 java InitFinalizeMain
>> Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library
>> /usr/local/openmpi-1.8.2_64_cc/lib64/libmpi_java.so.1.2.0 which
>> might have disabled stack guard. The VM will try to fix the stack
>> guard now.
>> It's highly recommended that you fix the library with
>> 'execstack -c ', or link it with '-z noexecstack'.
>> Hello!
>> linpc1 java 110 
>> 
>> 
>> I would be grateful if somebody can add the link option
>> '-z noexecstack' to omit the warning. Thank you very much for
>> your help in advance.
>> 
>> 
>> Kind regards
>> 
>> Siegmar
>> 
>> ___
>> users mailing list
>> us...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/users/2014/07/24871.php
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15267.php



Re: [OMPI devel] Fwd: [OMPI users] missing link option for openmpi-1.8.2rc2 on Linux

2014-07-25 Thread Jeff Squyres (jsquyres)
Understood.  I'm asking, in principle, as to whether we should use -z 
noexecstack for the whole thing -- i.e., is this just a good "best practice" 
kind of flag we should enable?


On Jul 25, 2014, at 12:02 PM, Ralph Castain  wrote:

> I think it's just libmpi_java that needs that linker flag, so it shouldn't 
> affect anyone else
> 
> On Jul 25, 2014, at 8:59 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> OMPI developers --
>> 
>> Is "-z noexecstack" a linker option we should test for in configure, and use 
>> it if it works?
>> 
>> Are there any side effects that could cause problems?
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: Siegmar Gross 
>>> Subject: [OMPI users] missing link option for openmpi-1.8.2rc2 on Linux
>>> Date: July 25, 2014 at 2:44:48 AM EDT
>>> To: 
>>> Reply-To: Siegmar Gross , Open MPI 
>>> Users 
>>> 
>>> Hi,
>>> 
>>> I installed openmpi-1.8.2rc2 on "openSUSE Linux 12.1 x86_64"
>>> with Sun C 5.12 and get the following warning if I run a small
>>> Java program. I get no warning for my gcc-4.9.0 version of
>>> openmpi-1.8.2rc2.
>>> 
>>> 
>>> linpc1 java 109 mpiexec -np 1 java InitFinalizeMain
>>> Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library
>>> /usr/local/openmpi-1.8.2_64_cc/lib64/libmpi_java.so.1.2.0 which
>>> might have disabled stack guard. The VM will try to fix the stack
>>> guard now.
>>> It's highly recommended that you fix the library with
>>> 'execstack -c ', or link it with '-z noexecstack'.
>>> Hello!
>>> linpc1 java 110 
>>> 
>>> 
>>> I would be grateful if somebody can add the link option
>>> '-z noexecstack' to omit the warning. Thank you very much for
>>> your help in advance.
>>> 
>>> 
>>> Kind regards
>>> 
>>> Siegmar
>>> 
>>> ___
>>> users mailing list
>>> us...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>> Link to this post: 
>>> http://www.open-mpi.org/community/lists/users/2014/07/24871.php
>> 
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15267.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/07/15268.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [OMPI devel] Trunk broken for --with-devel-headers?

2014-07-25 Thread Ralph Castain
Works okay with a fresh checkout, so something in my tree must have been hosed.


On Jul 25, 2014, at 8:51 AM, Ralph Castain  wrote:

> It seems to be only happening on my Mac, not Linux, but I'll try with a fresh 
> checkout
> 
> On Jul 25, 2014, at 8:51 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> I'm unable to replicate... perhaps you have a stale install tree?
>> 
>> 
>> On Jul 24, 2014, at 6:36 PM, Ralph Castain  wrote:
>> 
>>> Hey folks
>>> 
>>> Something in the last day or so appears to have broken the trunk's ability 
>>> to run --with-devel-headers. It looks like the headers are being installed 
>>> correctly, but mpicc fails to compile a program that uses them - the 
>>> include passes, but the linker fails:
>>> 
>>> Undefined symbols for architecture x86_64:
>>> "_opal_hwloc172_hwloc_bitmap_alloc", referenced from:
>>> _main in hello.o
>>> "_opal_hwloc172_hwloc_bitmap_list_asprintf", referenced from:
>>> _main in hello.o
>>> "_opal_hwloc172_hwloc_get_cpubind", referenced from:
>>> _main in hello.o
>>> "_opal_hwloc_topology", referenced from:
>>> _main in hello.o
>>> "_orte_process_info", referenced from:
>>> _main in hello.o
>>> ld: symbol(s) not found for architecture x86_64
>>> collect2: error: ld returned 1 exit status
>>> 
>>> Anybody else seeing this?
>>> Ralph
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post: 
>>> http://www.open-mpi.org/community/lists/devel/2014/07/15262.php
>> 
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/07/15265.php
>