gri6507 has asked for the wisdom of the Perl Monks concerning the following question:
Hello Monks,
I recently has the pleasure of having my old computer upgraded for me to a Win7-64 bit.
I put the 64-bit Strawberry Perl on that machine and tried to install the Win32::SerialPort module so that I could run one of my old scripts.
However, the installation did not work, failing on a number of tests.
This leads me to my questions:
- Should I even be able to run a 32-bit module for serial port communication on a 64-bit machine with a 64-bit perl?
- If I used a 32-bit Strawberry Perl instead, would I be able to run the 32-bit module, even though I am on a 64-bit machine?
- Is there some other SerialPort module that I should be using instead? (I've tried to install Device::Serial, but that failed to even run because it tries to configure with a *NIX ./configure script)
Your wisdom is appreciated.
Re: Using Win32::SerialPort on Win7-64bit under 64-bit Strawberry Perl
by dasgar (Priest) on Apr 24, 2014 at 22:17 UTC
|
Not sure why you're having problems with installing that module on 64-bit Perl. If you're looking for help with that, you can post more details here and ask for help from others and/or you can also submit a bug report with the module's maintainer.
If you wanted to use 32-bit Perl on 64-bit Windows, you can. You just won't be able to leverage any 64-bit features of Perl (such as 64-bit integers). Unless you really need those features, you shouldn't have a problem. In your case, it sounds like you're moving your existing script(s) from an older environment (presumably 32-bit OS & Perl), so using 32-bit Perl on 64-bit Windows won't be a problem. In my personal use, I haven't had a need for any 64-bit Perl features, so I've been sticking with 32-bit Perl even on 64-bit Windows.
As for using another module, the first obvious alternative is to use Win32API::CommPort, which Win32::SerialPort is using underneath and "provides an object-based user interface to allow higher-level use of common API call sequences for dealing with serial ports". However, I think I would prefer to stay with Win32::SerialPort myself.
| [reply] [Watch: Dir/Any] |
|
Based on the other response, I installed the 32-bit Strawberry Perl and tried to install Win32::Serial module there. However, I still ran into an installation problem. As requested, I'm posting my error here.
C:\strawberry\perl\bin>perl -MCPAN -e "install Win32::SerialPort"
Database was generated on Fri, 02 May 2014 14:16:35 GMT
Running install for module 'Win32::SerialPort'
Running make for B/BB/BBIRTH/Win32-SerialPort-0.22.tar.gz
Fetching with LWP:
http://cpan.strawberryperl.com/authors/id/B/BB/BBIRTH/Win32-SerialPort-0.22.tar.gz
Fetching with LWP:
http://cpan.strawberryperl.com/authors/id/B/BB/BBIRTH/CHECKSUMS
Checksum for C:\strawberry\cpan\sources\authors\id\B\BB\BBIRTH\Win32-SerialPort-0.22.tar.gz ok
CPAN.pm: Building B/BB/BBIRTH/Win32-SerialPort-0.22.tar.gz
found result=0, file=COM1
Win32::SerialPort and Win32API::CommPort
VERSION 0.22
A 'Makefile' created for those with 'make' or CPAN.pm users.
It will test using PORT = COM1. To test using a different PORT,
run again specifying: 'perl Makefile.PL TESTPORT=<PORT>'
The normal 'Mantra' would then apply:
make
make test
make install
For those without 'make' or an equivalent like 'nmake' or 'dmake' there
are perl-only scripts which do the same things:
Test with: perl nomake_test
Install with: perl nomake_install
Test with nothing connected to COM1.
PORT is not verified present and accessible until tests run.
Timeout tests can take up to 30 seconds per test.
Creating new t/DefaultPort.pm
Creating new nomake_test
Creating new nomake_install
Checking if your kit is complete...
Looks good
Generating a dmake-style Makefile
Writing Makefile for Win32::SerialPort
Writing MYMETA.yml and MYMETA.json
cp lib/Win32API/CommPort.pm blib\lib\Win32API\CommPort.pm
cp lib/Win32/SerialPort.pm blib\lib\Win32\SerialPort.pm
BBIRTH/Win32-SerialPort-0.22.tar.gz
C:\strawberry\c\bin\dmake.exe -- OK
Running make test
C:\strawberry\perl\bin\perl.exe "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
t/test1.t .. 224/309 can't get COMMPROP block at t/test1.t line 665.
can't get COMMPROP block at t/test1.t line 667.
can't get COMMPROP block at t/test1.t line 668.
can't get COMMPROP block at t/test1.t line 671.
can't get COMMPROP block at t/test1.t line 673.
# Failed test 'except zero if quiet'
# at t/test1.t line 673.
# got: undef
# expected: '0'
can't get COMMPROP block at t/test1.t line 674.
t/test1.t .. 305/309 # Looks like you failed 1 test of 309.
t/test1.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/309 subtests
t/test2.t .. ok
t/test3.t .. 239/? can't get COMMPROP block at t/test3.t line 699.
can't get COMMPROP block at t/test3.t line 701.
can't get COMMPROP block at t/test3.t line 702.
can't get COMMPROP block at t/test3.t line 705.
can't get COMMPROP block at t/test3.t line 707.
# Failed test 'quiet is one'
# at t/test3.t line 707.
# got: undef
# expected: '0'
can't get COMMPROP block at t/test3.t line 708.
can't get COMMPROP block at t/test3.t line 711.
can't get COMMPROP block at t/test3.t line 714.
can't get COMMPROP block at t/test3.t line 715.
# Looks like you failed 1 test of 264.
t/test3.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/264 subtests
t/test4.t .. ok
t/test5.t .. ok
t/test6.t .. 1/? SetCommState failed at t/test6.t line 306.
t/test6.t .. ok
t/test7.t .. ok
Test Summary Report
-------------------
t/test1.t (Wstat: 256 Tests: 309 Failed: 1)
Failed test: 236
Non-zero exit status: 1
t/test3.t (Wstat: 256 Tests: 264 Failed: 1)
Failed test: 254
Non-zero exit status: 1
Files=7, Tests=1808, 59 wallclock secs ( 0.31 usr + 0.03 sys = 0.34 CPU)
Result: FAIL
Failed 2/7 test programs. 2/1808 subtests failed.
dmake.exe: Error code 255, while making 'test_dynamic'
BBIRTH/Win32-SerialPort-0.22.tar.gz
C:\strawberry\c\bin\dmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports BBIRTH/Win32-SerialPort-0.22.tar.gz
Running make install
make test had returned bad status, won't install without force
Stopping: 'install' failed for 'Win32::SerialPort'. | [reply] [Watch: Dir/Any] |
|
I know that I personally have installed that module on 32-bit Strawberry Perl before.
Which version of Strawberry Perl are you using? You can verify which version you are using by running perl -v. If you can tell me which version you are using, I'd be willing to try installing Win32::SerialPort on that version to see if I can help you work through the issues.
| [reply] [Watch: Dir/Any] [d/l] |
|
|
|
Re: Using Win32::SerialPort on Win7-64bit under 64-bit Strawberry Perl
by Anonymous Monk on Apr 24, 2014 at 21:16 UTC
|
A few days ago user jismake reported having trouble with Win32::SerialPort on 64-bit Strawberry Perl on Win 7 64 bit that were solved by installing the 32-bit Strawberry Perl, although it was unclear whether the issue was with the module or with the virtual COM port drivers. That thread is here.
The "Win32" part of Win32::SerialPort does not necessarily mean that it is a 32-bit only module. Windows, even 64-bit, is still referred to "MSWin32" (e.g. $^O).
Having said that, it may very well be that a few bits of that module do not work right on 64-bit Windows, I don't know. CPAN Testers does show that tests on 64-bit Windows don't seem to pass, and even 32-bit is spotty.
I believe that Win32::SerialPort is "the" module for COM port access in Windows, and Device::SerialPort in *NIX.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Author here...As I said in response to the bug report, I don't consider it a bug. But it is true that the "make test" will fail badly if it doesn't see a hardware port. In 1999, when the test setup was initially designed, almost all systems DID have a COM1. And for the few exceptions, I allowed overriding the port from the command line. Since, at that time, very little installed cleanly from CPAN on Windows, I considered it adequate. The command line installer did not even need "make".
I run both 32 and 64 bit perls in parallel on my 64-bit windows box. I also have received some suggestions and patches to address actually running in a 64 bit perl. But I have been short of TUITs. I agree, the next update should include a no-hardware-detected default fallback. I'll make sure that is on the list and it should fix the CPAN concern, too.
-bill
| [reply] [Watch: Dir/Any] |
|
|