FAIL TermReadKey-2.30 MSWin32-x86-multi-thread 4.0
rr...@cpan.org
effort to test as many new uploads to CPAN as possible. See
http://testers.cpan.org/
Please cc any replies to cpan-t...@perl.org to keep other
test volunteers informed and to prevent any duplicate effort.
--
******************************** NOTE ********************************
The comments below are created mechanically, possibly without manual
checking by the sender. As there are many people performing automatic
tests on each upload to CPAN, it is likely that you will receive
identical messages about the same problem.
If you believe that the message is mistaken, please reply to the first
one with correction and/or additional information, and do not take
it personally. (We appreciate your patience. :)
**********************************************************************
Hello, JSTOWE! This is a computer-generated error report created
automatically by CPANPLUS, version 0.050_04.
Comments from the tester may appear at the end of this report, as well.
Thanks for uploading your works to CPAN. However, it appears that
CPANPLUS encountered problems while testing your distribution.
TEST RESULTS:
Below is the error stack from stage 'make test':
[MSG] [Thu Jan 13 18:51:44 2005] Trying to get 'ftp://ftp.cpan.org/pub/CPAN/authors/id/J/JS/JSTOWE/TermReadKey-2.30.tar.gz'
[MSG] [Thu Jan 13 18:51:49 2005] Trying to get 'ftp://ftp.cpan.org/pub/CPAN/authors/id/J/JS/JSTOWE/CHECKSUMS'
[MSG] [Thu Jan 13 18:51:52 2005] Checksum matches for 'TermReadKey-2.30.tar.gz'
[MSG] [Thu Jan 13 18:51:52 2005] Extracted 'TermReadKey-2.30/'
[MSG] [Thu Jan 13 18:51:52 2005] Extracted 'TermReadKey-2.30/genchars.pl'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/Makefile.PL'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/Configure.pm'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/test.pl'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/ReadKey.pm'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/META.yml'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/ReadKey.xs'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/ppport.h'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/MANIFEST'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/README'
[MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey' to 'C:\Documents and Settings\Rob.MAGNETO-XP\Application Data\.cpanplus\5.8.6\build\TermReadKey-2.30'
[ERROR] [Thu Jan 13 18:52:10 2005] MAKE TEST failed: No such file or directory C:\Perl\bin\perl.exe "-Iblib\lib" "-Iblib\arch" -w test.pl
1 .. 8
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
GetConsoleMode failed, LastError=|6| at blib\lib/Term/ReadKey.pm line 265.
END failed--call queue aborted.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x9'
Stop.
--
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl\lib\CORE" -machine:x86'
libpth=\lib
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl\lib\CORE" -machine:x86'
Jonathan Stowe
> [MSG] [Thu Jan 13 18:51:44 2005] Trying to get 'ftp://ftp.cpan.org/pub/CPAN/authors/id/J/JS/JSTOWE/TermReadKey-2.30.tar.gz'
> [MSG] [Thu Jan 13 18:51:49 2005] Trying to get 'ftp://ftp.cpan.org/pub/CPAN/authors/id/J/JS/JSTOWE/CHECKSUMS'
> [MSG] [Thu Jan 13 18:51:52 2005] Checksum matches for 'TermReadKey-2.30.tar.gz'
> [MSG] [Thu Jan 13 18:51:52 2005] Extracted 'TermReadKey-2.30/'
> [MSG] [Thu Jan 13 18:51:52 2005] Extracted 'TermReadKey-2.30/genchars.pl'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/Makefile.PL'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/Configure.pm'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/test.pl'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/ReadKey.pm'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/META.yml'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/ReadKey.xs'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/ppport.h'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/MANIFEST'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey-2.30/README'
> [MSG] [Thu Jan 13 18:51:53 2005] Extracted 'TermReadKey' to 'C:\Documents and Settings\Rob.MAGNETO-XP\Application Data\.cpanplus\5.8.6\build\TermReadKey-2.30'
> [ERROR] [Thu Jan 13 18:52:10 2005] MAKE TEST failed: No such file or directory C:\Perl\bin\perl.exe "-Iblib\lib" "-Iblib\arch" -w test.pl
This above looks like a problem with the testing environment and not the
program itself.
> 1 .. 8
> ok 1
> ok 2
> ok 3
> ok 4
> ok 5
> ok 6
> ok 7
> ok 8
>
> Microsoft (R) Program Maintenance Utility Version 1.50
> Copyright (c) Microsoft Corp 1988-94. All rights reserved.
>
> GetConsoleMode failed, LastError=|6| at blib\lib/Term/ReadKey.pm line 265.
> END failed--call queue aborted.
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x9'
> Stop.
>
Hmm. Most odd, it appears to have gone through all of the tests and then
failed at some point after the last test. I think this is probably at
the:
END { ReadMode 0, IN; }
which resets the terminal in case of a problem. The particularly
strange thing is that I PASS results on the same platform :-(
I'll try and get a system to test this on, but would it be possible to
run the test by hand (i.e. perl -Mblib test.pl in the directory where
the module was unpacked) and send me the results?
/J\
--
This e-mail is sponsored by http://www.integration-house.com/
Jonathan Stowe
Jonathan Stowe
> On Thu, 2005-01-13 at 18:52, rr...@cpan.org wrote:
> >
> > GetConsoleMode failed, LastError=|6| at blib\lib/Term/ReadKey.pm line 265.
> > END failed--call queue aborted.
> > NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x9'
> > Stop.
> >
>
> Hmm. Most odd, it appears to have gone through all of the tests and then
> failed at some point after the last test. I think this is probably at
> the:
>
> END { ReadMode 0, IN; }
>
> which resets the terminal in case of a problem. The particularly
> strange thing is that I PASS results on the same platform :-(
>
> I'll try and get a system to test this on, but would it be possible to
> run the test by hand (i.e. perl -Mblib test.pl in the directory where
> the module was unpacked) and send me the results?
>
Okay I have tracked this down to something strange going on with when
using the 'CONIN$' file - the test code (pared greatly down of course
does:
use Term::ReadKey;
use Fcntl;
sysopen( IN, 'CONIN$', O_RDWR );
ReadMode 0, IN;
Which fails with the above error. ReadMode (of course?) works fine for
STDIN.
On further examination I have distilled it down to:
Test.xs:
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "ppport.h"
#include <io.h>
MODULE = Test PACKAGE = Test
void Test(fh)
PerlIO *fh
CODE:
{
int handle;
HANDLE hwnd;
handle = PerlIO_fileno(fh);
if ((hwnd = (HANDLE)_get_osfhandle(handle)) == -1)
croak("bad file handle");
}
Test.t:
use Test
use Fcntl;
sysopen( IN, 'CONIN$', O_RDWR );
Test::Test(IN);
Which croaks with the message as above.
In normal usage CONIN$ and CONOUT$ work normally ( I can read, print and
take their fileno()).
So my question is: am I looking at a bug in the MS CRT here ( I am
testing with "Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
13.10.3077" i.e. the one that comes with Visual Studio 2003 ) and if so
are there any workarounds, or is this something strange (bug,
undocumented behaviour?) with PerlIO or indeed (quite likely) something
that I have missed and/or failed to understand. It occurs to me that it
could be something that is happening when the extension is compiled with
a diversion version of the compiler and/or CRT from that which compiled
the Perl but I am not in a position to test this right now.
Any input welcomed, especially testing with various MS compiler and Perl
versions.
Perl version:
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=def
ine
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32
-D_CONSOLE -
DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPL
ICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksi
ze=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf
-libpath:"C:
\Perl\lib\CORE" -machine:x86'
libpth=C:\PROGRA~1\MICROS~3\VC98\lib
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32
.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsoc
k32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comd
lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib
wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-opt:ref,icf -
libpath:"C:\Perl\lib\CORE" -machine:x86'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_
CONTEXT PERL_IMPLICIT_SYS
Locally applied patches:
ActivePerl Build 810
22751 Update to Test.pm 1.25
21540 Fix backward-compatibility issues in if.pm
Built under MSWin32
Compiled at Jun 1 2004 11:52:21
@INC:
C:/Perl/lib
C:/Perl/site/lib
.
/J\
Steve Hay
>On Fri, 2005-01-14 at 11:31, Jonathan Stowe wrote:
>
>
>>On Thu, 2005-01-13 at 18:52, rr...@cpan.org wrote:
>>
>>
>
>
>
>>>GetConsoleMode failed, LastError=|6| at blib\lib/Term/ReadKey.pm line 265.
>>>END failed--call queue aborted.
>>>NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x9'
>>>Stop.
>>>
I suspect that the problem is using the VC7 (aka Visual Studio 2003)
compiler with ActivePerl, which is built with VC6 (aka Visual Studio 98).
I've had error reports from the same cpan-tester in which this turned
out to be the problem, e.g. see:
http://www.mail-archive.com/cpan-t...@perl.org/msg157084.html
I tried your module using ActivePerl Build 810 and VC7 and got the same
error. Retrying with ActivePerl Build 810 and VC6 it works fine.
Trying again with VC7 but now using my own build of Perl also done with
VC7 it also works fine.
So it certainly looks like a CRT conflict in the ActivePerl/VC7 scenario
-- any time that you pass CRT resources between the msvc71.dll loaded by
your module's DLL and the msvcrt.dll loaded by ActivePerl's DLL you will
get problems. For example, in your XS above you open a file via
msvcrt.dll (the sysopen in Perl) and then pass the handle to msvc71.dll
(your XS code). The latter CRT doesn't think that the handle opened by
the former CRT is valid.
The only "solution" that I've come up with in cases where sharing CRT
resources in this way is unavoidable is to recommend that users use the
same compiler to build my modules as was used to build Perl. I don't
even have a good way of checking for this, so I just have a note in my
INSTALL file to this effect.
If anyone has any better solutions, I'd love to hear them!
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Steve Peters
> In principle would it be possible to determine the compiler and/or CRT
> version at configure time and make that available to test in cases like
> this?
>
Ideally, the compiler version should be held in Config.pm in the "ccversion" or
"gccversion" fields. If the configure process for Win32 was changed to
populate ccversion, then it would be trivial to check the compiler version
from the Config object.
Steve Peters
st...@fisharerojo.org
Jonathan Stowe
Yep, I can confirm this having had the opportunity to build a Perl on
windows.
> So it certainly looks like a CRT conflict in the ActivePerl/VC7 scenario
> -- any time that you pass CRT resources between the msvc71.dll loaded by
> your module's DLL and the msvcrt.dll loaded by ActivePerl's DLL you will
> get problems. For example, in your XS above you open a file via
> msvcrt.dll (the sysopen in Perl) and then pass the handle to msvc71.dll
> (your XS code). The latter CRT doesn't think that the handle opened by
> the former CRT is valid.
>
I think I must have been having a thick(er) moment on friday - on
inspection of the CRT source in the Windows SDK it is apparent that the
fileno is an index into an array of structs that holds among other
things the windows HANDLE to the file and that this array is static to
the instance of the CRT, so when you are using two separate CRT dlls
they are not going to have the same static information. I think I
already knew this :-(
> The only "solution" that I've come up with in cases where sharing CRT
> resources in this way is unavoidable is to recommend that users use the
> same compiler to build my modules as was used to build Perl. I don't
> even have a good way of checking for this, so I just have a note in my
> INSTALL file to this effect.
>
In this particular case (building an extension using a different MS C
compiler than that which built ActivePerl) it would be possible to
determine the particular build and the version of the C compiler you are
going to use (either by compiling and running a small program that
output the value of _MSC_VER or by examining CL.EXE's banner) and then
exit Makefile.PL with a message if they are incompatible. In the more
general case it becomes more difficult.
> If anyone has any better solutions, I'd love to hear them!
>
In principle would it be possible to determine the compiler and/or CRT
Randy Kobes
[ .. ]
> Yes, $Config{[g]ccversion} should really hold the compiler
> version, but currently doesn't. I can fix that fairly
> easily for cl and gcc. (I don't know about Borland's
> compiler.)
>
> This well help in the future, so is worth doing, but
> clearly doesn't help in spotting conflicts in existing
> Perls which are out there :(
I'm not sure how general this is, but for ActivePerl built
with VC++ 6,
C:\> perl -V:libs
includes ws2_32.lib, whereas, for example,
http://www.nntp.perl.org/group/perl.cpan.testers/178539
(using VC++ Toolkit 2003) has instead wsock32.lib.
--
best regards,
randy kobes