GNU bug report logs -
#14707
automake 1.14 test hang for t/compile4.sh on Linux if "cl" executable is in path
Previous Next
Reported by: Diab Jerius <dj <at> head.cfa.harvard.edu>
Date: Mon, 24 Jun 2013 15:52:04 UTC
Severity: minor
Tags: patch
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14707 in the body.
You can then email your comments to 14707 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Mon, 24 Jun 2013 15:52:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Diab Jerius <dj <at> head.cfa.harvard.edu>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Mon, 24 Jun 2013 15:52:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
On the Linux boxes I compile on, there's a /usr/local/bin/cl executable
(from the IRAF package). Unfortunately, it seems that t/compile4.sh
interprets that as a Microsoft compiler.
The IRAF cl is an interactive program, so compile4.sh invokes it and it
hangs waiting for input.
Is there perhaps a better way of checking for the Microsoft compiler, or
restricting these tests to Microsoft operating systems?
Thanks,
Diab
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Mon, 24 Jun 2013 21:23:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 14707 <at> debbugs.gnu.org (full text, mbox):
severity 14707 minor
tags 14707 + moreinfo
thanks
On 06/24/2013 04:45 PM, Diab Jerius wrote:
> Hi,
>
Hi Diab, thanks for the report.
> On the Linux boxes I compile on, there's a /usr/local/bin/cl executable
> (from the IRAF package). Unfortunately, it seems that t/compile4.sh
> interprets that as a Microsoft compiler.
>
> The IRAF cl is an interactive program,
>
What happens if the program is run with its stdin redirected from /dev/null?
Does it exit immediately, or does it still hang? Also, does the program
support a --version or --help option that might lead us to rule it out?
> so compile4.sh invokes it and it hangs waiting for input.
>
(Which is quite annoying indeed).
> Is there perhaps a better way of checking for the Microsoft compiler, or
> restricting these tests to Microsoft operating systems?
>
I'd rather try the workarounds I proposed above first. If they don't
work, we should go along with your suggestion.
Thank you,
Stefano
Severity set to 'minor' from 'normal'
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 24 Jun 2013 21:23:03 GMT)
Full text and
rfc822 format available.
Added tag(s) moreinfo.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 24 Jun 2013 21:23:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Mon, 24 Jun 2013 21:36:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 14707 <at> debbugs.gnu.org (full text, mbox):
On Mon, 2013-06-24 at 23:22 +0200, Stefano Lattarini wrote:
> severity 14707 minor
> tags 14707 + moreinfo
> thanks
>
> On 06/24/2013 04:45 PM, Diab Jerius wrote:
> > Hi,
> >
> Hi Diab, thanks for the report.
Stefano,
Thanks for the reply.
>
> > On the Linux boxes I compile on, there's a /usr/local/bin/cl executable
> > (from the IRAF package). Unfortunately, it seems that t/compile4.sh
> > interprets that as a Microsoft compiler.
> >
> > The IRAF cl is an interactive program,
> >
> What happens if the program is run with its stdin redirected from /dev/null?
> Does it exit immediately, or does it still hang?
It exits, quite verbosely:
% cl < /dev/null
Warning: no login.cl found in login directory
apropos fitsutil lists phist stecf utilities
color gemini mscred plot stlocal xray
ctio gmisc nmisc proto stsdas
dataio images noao rvsao system
dbms language obsolete softools tables
ecl> ERROR: use `logout' to log out of the CL
ecl> ERROR: use `logout' to log out of the CL
ecl> ERROR: use `logout' to log out of the CL
ecl> ERROR: use `logout' to log out of the CL
ecl> ERROR: use `logout' to log out of the CL
ecl> ERROR: use `logout' to log out of the CL
ecl> ERROR: use `logout' to log out of the CL
ecl> ERROR: use `logout' to log out of the CL
ecl> %
> Also, does the program support a --version or --help option that might
> lead us to rule it out?
Indeed, it does:
% cl --version
NOAO/IRAFNET PC-IRAF Revision 2.14.1 Mon Sep 15 10:12:05 MST 2008
>
> > so compile4.sh invokes it and it hangs waiting for input.
> >
> (Which is quite annoying indeed).
>
> > Is there perhaps a better way of checking for the Microsoft compiler, or
> > restricting these tests to Microsoft operating systems?
> >
> I'd rather try the workarounds I proposed above first. If they don't
> work, we should go along with your suggestion.
>
> Thank you,
> Stefano
Thanks,
Diab
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Tue, 25 Jun 2013 16:13:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 14707 <at> debbugs.gnu.org (full text, mbox):
On Mon, 2013-06-24 at 23:22 +0200, Stefano Lattarini wrote:
> severity 14707 minor
> tags 14707 + moreinfo
> thanks
>
> On 06/24/2013 04:45 PM, Diab Jerius wrote:
> > Hi,
> >
> Hi Diab, thanks for the report.
>
> > On the Linux boxes I compile on, there's a /usr/local/bin/cl executable
> > (from the IRAF package). Unfortunately, it seems that t/compile4.sh
> > interprets that as a Microsoft compiler.
> >
> > The IRAF cl is an interactive program,
> >
> What happens if the program is run with its stdin redirected from /dev/null?
> Does it exit immediately, or does it still hang? Also, does the program
> support a --version or --help option that might lead us to rule it out?
>
> > so compile4.sh invokes it and it hangs waiting for input.
> >
> (Which is quite annoying indeed).
>
> > Is there perhaps a better way of checking for the Microsoft compiler, or
> > restricting these tests to Microsoft operating systems?
> >
> I'd rather try the workarounds I proposed above first. If they don't
> work, we should go along with your suggestion.
>
> Thank you,
> Stefano
As the tests progress, it looks like there are more with the same issue.
For completeness, here's the list:
t/compile4.sh
t/depcomp-lt-msvcmsys.tap
t/depcomp-lt-msvisualcpp.tap
t/depcomp-msvcmsys.tap
t/depcomp-msvisualcpp.tap
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Thu, 27 Jun 2013 08:51:03 GMT)
Full text and
rfc822 format available.
Message #21 received at 14707 <at> debbugs.gnu.org (full text, mbox):
On 06/25/2013 06:12 PM, Diab Jerius wrote:
> On Mon, 2013-06-24 at 23:22 +0200, Stefano Lattarini wrote:
>> severity 14707 minor
>> tags 14707 + moreinfo
>> thanks
>>
>> On 06/24/2013 04:45 PM, Diab Jerius wrote:
>>> Hi,
>>>
>> Hi Diab, thanks for the report.
>>
>>> On the Linux boxes I compile on, there's a /usr/local/bin/cl executable
>>> (from the IRAF package). Unfortunately, it seems that t/compile4.sh
>>> interprets that as a Microsoft compiler.
>>>
>>> The IRAF cl is an interactive program,
>>>
>> What happens if the program is run with its stdin redirected from /dev/null?
>> Does it exit immediately, or does it still hang? Also, does the program
>> support a --version or --help option that might lead us to rule it out?
>>
>>> so compile4.sh invokes it and it hangs waiting for input.
>>>
>> (Which is quite annoying indeed).
>>
>>> Is there perhaps a better way of checking for the Microsoft compiler, or
>>> restricting these tests to Microsoft operating systems?
>>>
>> I'd rather try the workarounds I proposed above first. If they don't
>> work, we should go along with your suggestion.
>>
>> Thank you,
>> Stefano
>
> As the tests progress, it looks like there are more with the
> same issue.
>
Not to worry, those tests all share the same code for requesting
prerequisites, so the all the issues should disappear once we
fix the code for the "cl" requirement. Patch coming up soon...
> For completeness, here's the list:
>
> t/compile4.sh
> t/depcomp-lt-msvcmsys.tap
> t/depcomp-lt-msvisualcpp.tap
> t/depcomp-msvcmsys.tap
> t/depcomp-msvisualcpp.tap
>
>
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Thu, 27 Jun 2013 09:21:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 14707 <at> debbugs.gnu.org (full text, mbox):
tags 14707 + patch
tags 14707 - moreinfo
thanks
On 06/24/2013 11:35 PM, Diab Jerius wrote:
>
> On Mon, 2013-06-24 at 23:22 +0200, Stefano Lattarini wrote:
>>
>> On 06/24/2013 04:45 PM, Diab Jerius wrote:
>>>
>>> On the Linux boxes I compile on, there's a /usr/local/bin/cl executable
>>> (from the IRAF package). Unfortunately, it seems that t/compile4.sh
>>> interprets that as a Microsoft compiler.
>>>
>>> The IRAF cl is an interactive program,
>>>
>> What happens if the program is run with its stdin redirected from /dev/null?
>> Does it exit immediately, or does it still hang?
>
> It exits, quite verbosely:
>
> % cl < /dev/null
> Warning: no login.cl found in login directory
> apropos fitsutil lists phist stecf utilities
> color gemini mscred plot stlocal xray
> ctio gmisc nmisc proto stsdas
> dataio images noao rvsao system
> dbms language obsolete softools tables
>
> ecl> ERROR: use `logout' to log out of the CL
> ecl> ERROR: use `logout' to log out of the CL
> ecl> ERROR: use `logout' to log out of the CL
> ecl> ERROR: use `logout' to log out of the CL
> ecl> ERROR: use `logout' to log out of the CL
> ecl> ERROR: use `logout' to log out of the CL
> ecl> ERROR: use `logout' to log out of the CL
> ecl> ERROR: use `logout' to log out of the CL
> ecl> %
>
Thanks, this is what I needed. Below is a patch that I hope should
fix your problem. Can you give it a try?
>> Also, does the program support a --version or --help option that might
>> lead us to rule it out?
>
> Indeed, it does:
>
> % cl --version
> NOAO/IRAFNET PC-IRAF Revision 2.14.1 Mon Sep 15 10:12:05 MST 2008
>
>>
>>> so compile4.sh invokes it and it hangs waiting for input.
>>>
>> (Which is quite annoying indeed).
Thanks,
Stefano
---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----
From ec163633dd590bfdbd8d7fd147492081018507f7 Mon Sep 17 00:00:00 2001
Message-Id: <ec163633dd590bfdbd8d7fd147492081018507f7.1372324708.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Thu, 27 Jun 2013 11:11:35 +0200
Subject: [PATCH] tests: don't risk hanging on the 'cl' requirement
On the GNU/Linux boxes of some users that run our testsuite there
is a '/usr/local/bin/cl' executable, from the IRAF package:
<http://iraf.noao.edu/>
The test 'compile4.sh' (and other tests) try to invoke the 'cl'
command to check whether it's a Microsoft compiler; the IRAF cl
is an interactive program, so it hangs on such invocation. In
conclusion, the testsuite hangs for those users which have the
IRAF cl early in PATH.
Fix the issue by redirecting the input of cl from /dev/null when
invoking it, which is enough to prevent the cl program from IRAF
from hanging, and should have no effect on the behaviour of the
Microsoft compiler.
This change fixes automake bug#14707.
* t/ax/am-test-lib.sh (require_tool): Adjust the handling of
the 'cl' requirement.
Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
t/ax/am-test-lib.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/t/ax/am-test-lib.sh b/t/ax/am-test-lib.sh
index 182b070..26e58ef 100644
--- a/t/ax/am-test-lib.sh
+++ b/t/ax/am-test-lib.sh
@@ -788,7 +788,11 @@ require_tool ()
# in the environment "by hand" before calling the testsuite.
export CC CPPFLAGS
echo "$me: running $CC -?"
- $CC -? || skip_all_ "Microsoft C compiler '$CC' not available"
+ # The IRAF package (http://iraf.noao.edu/) contains a 'cl' program
+ # which is interactive, and which could cause the testsuite to hang
+ # if its standard input is not redirected. See automake bug#14707.
+ $CC -? </dev/null \
+ || skip_all_ "Microsoft C compiler '$CC' not available"
;;
etags)
# Exuberant Ctags will create a TAGS file even
--
1.8.3.1.448.gfb7dfaa
Added tag(s) patch.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 27 Jun 2013 09:21:03 GMT)
Full text and
rfc822 format available.
Removed tag(s) moreinfo.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 27 Jun 2013 09:21:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Fri, 28 Jun 2013 21:26:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 14707 <at> debbugs.gnu.org (full text, mbox):
On Thu, 2013-06-27 at 11:20 +0200, Stefano Lattarini wrote:
> tags 14707 + patch
> tags 14707 - moreinfo
> thanks
>
> On 06/24/2013 11:35 PM, Diab Jerius wrote:
> >
> > On Mon, 2013-06-24 at 23:22 +0200, Stefano Lattarini wrote:
> >>
> >> On 06/24/2013 04:45 PM, Diab Jerius wrote:
> >>>
> >>> On the Linux boxes I compile on, there's a /usr/local/bin/cl executable
> >>> (from the IRAF package). Unfortunately, it seems that t/compile4.sh
> >>> interprets that as a Microsoft compiler.
> >>>
> >>> The IRAF cl is an interactive program,
> >>>
> >> What happens if the program is run with its stdin redirected from /dev/null?
> >> Does it exit immediately, or does it still hang?
> >
> > It exits, quite verbosely:
> >
> > % cl < /dev/null
> > Warning: no login.cl found in login directory
> > apropos fitsutil lists phist stecf utilities
> > color gemini mscred plot stlocal xray
> > ctio gmisc nmisc proto stsdas
> > dataio images noao rvsao system
> > dbms language obsolete softools tables
> >
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> ERROR: use `logout' to log out of the CL
> > ecl> %
> >
> Thanks, this is what I needed. Below is a patch that I hope should
> fix your problem. Can you give it a try?
>
That fixes the problem.
Thanks,
Diab
Information forwarded
to
bug-automake <at> gnu.org
:
bug#14707
; Package
automake
.
(Sun, 07 Jul 2013 09:29:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 14707 <at> debbugs.gnu.org (full text, mbox):
On 06/28/2013 10:25 PM, Diab Jerius wrote:
>
> That fixes the problem.
>
> Thanks,
>
> Diab
>
Thanks for confirming. I will push the patch soonish
then (maybe a few days).
Best regards,
Stefano
Reply sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>
:
You have taken responsibility.
(Sun, 21 Jul 2013 12:16:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Diab Jerius <dj <at> head.cfa.harvard.edu>
:
bug acknowledged by developer.
(Sun, 21 Jul 2013 12:16:03 GMT)
Full text and
rfc822 format available.
Message #39 received at 14707-done <at> debbugs.gnu.org (full text, mbox):
Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14707>
On 06/28/2013 10:25 PM, Diab Jerius wrote:
>
> [SNIP]
>
> That fixes the problem.
>
Thanks, will push shortly then. I'm also closing the bug report.
Best regards,
Stefano
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 19 Aug 2013 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 312 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.