Re: [OMPI devel] basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

2013-07-12 Thread Vasiliy 
Oh, sorry. It is an Automake bug in terms of reacting to the
--log-file option, but 'basename' tells also it does not understand /
do not pass --test-name to 'test-driver', which, in turn, triggers the
above failure for yet another reason. So, it is combined.

On Thu, Jul 11, 2013 at 11:18 PM, Jeff Squyres (jsquyres)
 wrote:
> I'm not sure what you're saying -- isn't this an Automake bug?
>
> Or are you saying that we're doing something wrong in OMPI's Makefile.am's?
>
>
>
> On Jul 11, 2013, at 7:47 AM, Vasiliy  wrote:
>
>> I've also tracked down that problem with 'test-driver'. Look at that:
>>
>> $ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver
>> GNU gdb (GDB) 7.6.50.20130320-cvs
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-unknown-cygwin".
>> For bug reporting instructions, please see:
>> ...
>> Reading symbols from /usr/bin/sh...Reading symbols from
>> /usr/lib/debug/usr/bin/sh.exe.dbg...done.
>> done.
>> (gdb) run
>> Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
>> [New Thread 9900.0xc10]
>> [New Thread 9900.0x1bec]
>> [New Thread 9900.0xe38]
>> /usr/share/automake-1.14/test-driver: line 95: $log_file: ambiguous redirect
>> FAIL:
>> /usr/share/automake-1.14/test-driver: line 114: $trs_file: ambiguous redirect
>> /usr/share/automake-1.14/test-driver: line 115: $trs_file: ambiguous redirect
>> /usr/share/automake-1.14/test-driver: line 116: $trs_file: ambiguous redirect
>> /usr/share/automake-1.14/test-driver: line 117: $trs_file: ambiguous redirect
>> [Inferior 1 (process 9900) exited with code 01]
>> (gdb) quit
>>
>> $ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver --log-file=/tmp
>> GNU gdb (GDB) 7.6.50.20130320-cvs
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-unknown-cygwin".
>> For bug reporting instructions, please see:
>> ...
>> Reading symbols from /usr/bin/sh...Reading symbols from
>> /usr/lib/debug/usr/bin/sh.exe.dbg...done.
>> done.
>> (gdb) run
>> Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
>> --log-file=/tmp
>> [New Thread 2164.0x164c]
>> [New Thread 2164.0x24a4]
>> [New Thread 2164.0x2550]
>> /usr/share/automake-1.14/test-driver: invalid option: '--log-file=/tmp'
>> [New Thread 2164.0x19d4]
>> Usage:
>>  test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
>>  [--expect-failure={yes|no}] [--color-tests={yes|no}]
>>  [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
>> The '--test-name', '--log-file' and '--trs-file' options are mandatory.
>>
>> So, there is a problem with 'test-driver' either because a testsuite
>> does not provide --test-name=NAME or because --log-file=/tmp or
>> --log-file=/tmp/delme is wrongly considered an invalid option. It
>> applies to automake 1.13 as well.
>>
>> Could an Open MPI Team suggest if we could change that behavior, or,
>> at least, make omitting --test-name not so critical?
>>
>>
>> -- Forwarded message --
>> From: Vasiliy
>> Date: Thu, Jul 11, 2013 at 1:31 PM
>> Subject: basename: a faulty warning 'extra operand --test-name' in
>> tests causes test-driver to fail
>> To: Open MPI Developers
>>
>>
>> upon inspecting:
>> $ /usr/share/automake-1.14/test-driver --help
>> Usage:
>>  test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
>>  [--expect-failure={yes|no}] [--color-tests={yes|no}]
>>  [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
>> The '--test-name', '--log-file' and '--trs-file' options are mandatory.
>> 
>> make  check-TESTS
>> make[1]: Entering directory
>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
>> make[2]: Entering directory
>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> ...
>>
>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/config/test-driver:
>> line 95:   Segmentation fault  (core dumped) "$@" > $log_file
>> 2>&1
>> 
>> __

Re: [OMPI devel] basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

2013-07-12 Thread Jeff Squyres (jsquyres) 
I'm sorry, I'm still unclear what you're trying to tell us.  :-(

1. What version of Open MPI are you testing?  If you're testing Open MPI 1.6.x 
with very new Automake, I'm not surprised that there's some failures.  We 
usually pick the newest GNU Autotools when we begin a release series, and then 
stick with those tool versions for the life of that series.  We do not attempt 
to forward-port to newer Autotools on that series, meaning that sometimes newer 
versions of the Autotools will break the builds of that series.  That's ok.

2. Assumedly, you're seeing this failure when you run "make check".  Is that 
correct?  What test, exactly, is failing?  It's very difficult to grok what 
you're reporting when you only include the last few lines of output, which 
exclude the majority of the context that we need to know what you're talking 
about.

Your bug reports have been *extremely* helpful in cleaning out some old kruft 
from our tree, but could you include more context in the future?  E.g., include 
all the "compile problems" items from here:

http://www.open-mpi.org/community/help/

3. We don't have a test named "basename" or "test-driver"; basename is usually 
an OS utility, and test-driver is part of the new Automake testing framework.  
If there's a mistake in how these are being invoked, it's coming from Automake, 
and you should report the bug to them.  

...unless we're doing something wrong in our Makefile.am's in how we list the 
tests to be run.  Is that what you're saying?


On Jul 12, 2013, at 3:59 AM, Vasiliy  wrote:

> Oh, sorry. It is an Automake bug in terms of reacting to the
> --log-file option, but 'basename' tells also it does not understand /
> do not pass --test-name to 'test-driver', which, in turn, triggers the
> above failure for yet another reason. So, it is combined.
> 
> On Thu, Jul 11, 2013 at 11:18 PM, Jeff Squyres (jsquyres)
>  wrote:
>> I'm not sure what you're saying -- isn't this an Automake bug?
>> 
>> Or are you saying that we're doing something wrong in OMPI's Makefile.am's?
>> 
>> 
>> 
>> On Jul 11, 2013, at 7:47 AM, Vasiliy  wrote:
>> 
>>> I've also tracked down that problem with 'test-driver'. Look at that:
>>> 
>>> $ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver
>>> GNU gdb (GDB) 7.6.50.20130320-cvs
>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> 
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-unknown-cygwin".
>>> For bug reporting instructions, please see:
>>> ...
>>> Reading symbols from /usr/bin/sh...Reading symbols from
>>> /usr/lib/debug/usr/bin/sh.exe.dbg...done.
>>> done.
>>> (gdb) run
>>> Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
>>> [New Thread 9900.0xc10]
>>> [New Thread 9900.0x1bec]
>>> [New Thread 9900.0xe38]
>>> /usr/share/automake-1.14/test-driver: line 95: $log_file: ambiguous redirect
>>> FAIL:
>>> /usr/share/automake-1.14/test-driver: line 114: $trs_file: ambiguous 
>>> redirect
>>> /usr/share/automake-1.14/test-driver: line 115: $trs_file: ambiguous 
>>> redirect
>>> /usr/share/automake-1.14/test-driver: line 116: $trs_file: ambiguous 
>>> redirect
>>> /usr/share/automake-1.14/test-driver: line 117: $trs_file: ambiguous 
>>> redirect
>>> [Inferior 1 (process 9900) exited with code 01]
>>> (gdb) quit
>>> 
>>> $ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver 
>>> --log-file=/tmp
>>> GNU gdb (GDB) 7.6.50.20130320-cvs
>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> 
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-unknown-cygwin".
>>> For bug reporting instructions, please see:
>>> ...
>>> Reading symbols from /usr/bin/sh...Reading symbols from
>>> /usr/lib/debug/usr/bin/sh.exe.dbg...done.
>>> done.
>>> (gdb) run
>>> Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
>>> --log-file=/tmp
>>> [New Thread 2164.0x164c]
>>> [New Thread 2164.0x24a4]
>>> [New Thread 2164.0x2550]
>>> /usr/share/automake-1.14/test-driver: invalid option: '--log-file=/tmp'
>>> [New Thread 2164.0x19d4]
>>> Usage:
>>> test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
>>> [--expect-failure={yes|no}] [--color-tests={yes|no}]
>>> [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
>>> The '--test-name', '--log-file' and '--trs-file' options are mandatory.
>>> 
>>> So, there is a problem with 'test-driver' either because a testsuite
>>> does not provide --test-name=NAME or be

Re: [OMPI devel] basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

2013-07-12 Thread Vasiliy 
Sorry again, my report was a stub because I didn't have enough time to
investigate the issue. Due to the verbose level was set to zero, I've
assumed from the log that 'basename' belongs to the Open MPI source
whereas it is not. Thank you for drawing my attention it's actually a
utility from 'coreutils' Cygwin package. I'll report it to their team.
I've also filed a report with Automake's team about their part.

1. I'm testing the Open MPI SVN patched source, that is, 1.9a1-svn
with the latest autotools assembled from their git/svn sources, and my
humble patches, yet have to be polished.

2. Indeed, I'm running 'make check' when seeing those failures.
Unfortunately, that failure with 'test-driver' obscures how many (how
less), if any, true tests have been failed. I've just run it now on
the latest sources (bzw, there's still an old rot with 'trace.c') and,
if I could manage to make 'test-drive' working, it passes *ALL* the
tests, except those with bogus 'test-drive' crashes, that is:

atomic_spinlock_noinline.exe
atomic_cmpset_noinline.exe
atomic_math_noinline.exe
atomic_spinlock_noinline.exe
atomic_cmpset_noinline.exe
atomic_spinlock_noinline.exe
atomic_math_noinline.exe
atomic_cmpset_noinline.exe
atomic_spinlock_noinline.exe
atomic_math_noinline.exe
atomic_spinlock_noinline.exe
atomic_cmpset_noinline.exe
atomic_math_noinline.exe

Clearly, they're inline/noinline issues, need to be looked into at
some time later.

I can now give a feedback why I've got early reported warning about
the shared libraries which haven't got created, and a blowout of
'undefined symbols'. Indeed, that was a problem with Makefile.am's.
I've tested just two from about a hundred of other successfully
compiled static libraries, which DSO counterparts weren't created upon
compilation process, though being requested to:

- 'ompi/datatype's Makefile compiles 'libdatatype' without very much
needed 'libopen-pal' and 'libmpi' libraries, what causes a shared
library not to be created because of undefined symbols; bzw, even if
added to the libtool (v2.4.2-374) invocation command line they are
still not being produced, gcc doesn't have this kind of a problem;

- 'ompi/debuggers's Makefile does not make a 'libompi_dbg_msgq.dll.a'
import library (though there is a shared library), the corresponding
part has to be created manually;

I haven't checked other 95's.



On Fri, Jul 12, 2013 at 2:26 PM, Jeff Squyres (jsquyres)
 wrote:
> I'm sorry, I'm still unclear what you're trying to tell us.  :-(
>
> 1. What version of Open MPI are you testing?  If you're testing Open MPI 
> 1.6.x with very new Automake, I'm not surprised that there's some failures.  
> We usually pick the newest GNU Autotools when we begin a release series, and 
> then stick with those tool versions for the life of that series.  We do not 
> attempt to forward-port to newer Autotools on that series, meaning that 
> sometimes newer versions of the Autotools will break the builds of that 
> series.  That's ok.
>
> 2. Assumedly, you're seeing this failure when you run "make check".  Is that 
> correct?  What test, exactly, is failing?  It's very difficult to grok what 
> you're reporting when you only include the last few lines of output, which 
> exclude the majority of the context that we need to know what you're talking 
> about.
>
> Your bug reports have been *extremely* helpful in cleaning out some old kruft 
> from our tree, but could you include more context in the future?  E.g., 
> include all the "compile problems" items from here:
>
> http://www.open-mpi.org/community/help/
>
> 3. We don't have a test named "basename" or "test-driver"; basename is 
> usually an OS utility, and test-driver is part of the new Automake testing 
> framework.  If there's a mistake in how these are being invoked, it's coming 
> from Automake, and you should report the bug to them.
>
> ...unless we're doing something wrong in our Makefile.am's in how we list the 
> tests to be run.  Is that what you're saying?
>
>
> On Jul 12, 2013, at 3:59 AM, Vasiliy  wrote:
>
>> Oh, sorry. It is an Automake bug in terms of reacting to the
>> --log-file option, but 'basename' tells also it does not understand /
>> do not pass --test-name to 'test-driver', which, in turn, triggers the
>> above failure for yet another reason. So, it is combined.
>>
>> On Thu, Jul 11, 2013 at 11:18 PM, Jeff Squyres (jsquyres)
>>  wrote:
>>> I'm not sure what you're saying -- isn't this an Automake bug?
>>>
>>> Or are you saying that we're doing something wrong in OMPI's Makefile.am's?
>>>
>>>
>>>
>>> On Jul 11, 2013, at 7:47 AM, Vasiliy  wrote:
>>>
 I've also tracked down that problem with 'test-driver'. Look at that:

 $ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver
 GNU gdb (GDB) 7.6.50.20130320-cvs
 Copyright (C) 2013 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later 
 
 This is free software: you are free to change and

Re: [OMPI devel] basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

2013-07-12 Thread Vasiliy 
I've just gone through a test suite, and in 'test/asm/run_tests' there
is a statement:

progname="`basename $*`"

where '--test-name' could accidentally get in, causing the reported
issues, since 'basename' does not have such an option. Somebody
familiar with a test suite may want to look into it.

On Fri, Jul 12, 2013 at 5:17 PM, Vasiliy  wrote:
> Sorry again, my report was a stub because I didn't have enough time to
> investigate the issue. Due to the verbose level was set to zero, I've
> assumed from the log that 'basename' belongs to the Open MPI source
> whereas it is not. Thank you for drawing my attention it's actually a
> utility from 'coreutils' Cygwin package. I'll report it to their team.
> I've also filed a report with Automake's team about their part.
>
> 1. I'm testing the Open MPI SVN patched source, that is, 1.9a1-svn
> with the latest autotools assembled from their git/svn sources, and my
> humble patches, yet have to be polished.
>
> 2. Indeed, I'm running 'make check' when seeing those failures.
> Unfortunately, that failure with 'test-driver' obscures how many (how
> less), if any, true tests have been failed. I've just run it now on
> the latest sources (bzw, there's still an old rot with 'trace.c') and,
> if I could manage to make 'test-drive' working, it passes *ALL* the
> tests, except those with bogus 'test-drive' crashes, that is:
>
> atomic_spinlock_noinline.exe
> atomic_cmpset_noinline.exe
> atomic_math_noinline.exe
> atomic_spinlock_noinline.exe
> atomic_cmpset_noinline.exe
> atomic_spinlock_noinline.exe
> atomic_math_noinline.exe
> atomic_cmpset_noinline.exe
> atomic_spinlock_noinline.exe
> atomic_math_noinline.exe
> atomic_spinlock_noinline.exe
> atomic_cmpset_noinline.exe
> atomic_math_noinline.exe
>
> Clearly, they're inline/noinline issues, need to be looked into at
> some time later.
>
> I can now give a feedback why I've got early reported warning about
> the shared libraries which haven't got created, and a blowout of
> 'undefined symbols'. Indeed, that was a problem with Makefile.am's.
> I've tested just two from about a hundred of other successfully
> compiled static libraries, which DSO counterparts weren't created upon
> compilation process, though being requested to:
>
> - 'ompi/datatype's Makefile compiles 'libdatatype' without very much
> needed 'libopen-pal' and 'libmpi' libraries, what causes a shared
> library not to be created because of undefined symbols; bzw, even if
> added to the libtool (v2.4.2-374) invocation command line they are
> still not being produced, gcc doesn't have this kind of a problem;
>
> - 'ompi/debuggers's Makefile does not make a 'libompi_dbg_msgq.dll.a'
> import library (though there is a shared library), the corresponding
> part has to be created manually;
>
> I haven't checked other 95's.
>
>
>
> On Fri, Jul 12, 2013 at 2:26 PM, Jeff Squyres (jsquyres)
>  wrote:
>> I'm sorry, I'm still unclear what you're trying to tell us.  :-(
>>
>> 1. What version of Open MPI are you testing?  If you're testing Open MPI 
>> 1.6.x with very new Automake, I'm not surprised that there's some failures.  
>> We usually pick the newest GNU Autotools when we begin a release series, and 
>> then stick with those tool versions for the life of that series.  We do not 
>> attempt to forward-port to newer Autotools on that series, meaning that 
>> sometimes newer versions of the Autotools will break the builds of that 
>> series.  That's ok.
>>
>> 2. Assumedly, you're seeing this failure when you run "make check".  Is that 
>> correct?  What test, exactly, is failing?  It's very difficult to grok what 
>> you're reporting when you only include the last few lines of output, which 
>> exclude the majority of the context that we need to know what you're talking 
>> about.
>>
>> Your bug reports have been *extremely* helpful in cleaning out some old 
>> kruft from our tree, but could you include more context in the future?  
>> E.g., include all the "compile problems" items from here:
>>
>> http://www.open-mpi.org/community/help/
>>
>> 3. We don't have a test named "basename" or "test-driver"; basename is 
>> usually an OS utility, and test-driver is part of the new Automake testing 
>> framework.  If there's a mistake in how these are being invoked, it's coming 
>> from Automake, and you should report the bug to them.
>>
>> ...unless we're doing something wrong in our Makefile.am's in how we list 
>> the tests to be run.  Is that what you're saying?
>>
>>
>> On Jul 12, 2013, at 3:59 AM, Vasiliy  wrote:
>>
>>> Oh, sorry. It is an Automake bug in terms of reacting to the
>>> --log-file option, but 'basename' tells also it does not understand /
>>> do not pass --test-name to 'test-driver', which, in turn, triggers the
>>> above failure for yet another reason. So, it is combined.
>>>
>>> On Thu, Jul 11, 2013 at 11:18 PM, Jeff Squyres (jsquyres)
>>>  wrote:
 I'm not sure what you're saying -- isn't this an Automake bug?

 Or are you saying that we're