Re: Request for more functionality in Math::BigFloat
- Original Message -
From: Geoff Horsnell ge...@horsnell.freeserve.co.uk
To: perl-win32-users@listserv.activestate.com
Sent: Wednesday, July 02, 2014 12:34 AM
Subject: Request for more functionality in Math::BigFloat
Has anyone extended the Math::BigFloat package to include such niceties as
the INT function, or remaindering? I need to be able to do some large
calculations and those two functions would be very useful additions to the
Math::BigFloat package
I think the functionality you seek is already there:
#
#!perl -l
use strict;
use warnings;
use Math::BigFloat;
use Math::BigInt;
my $str = ('987' x 12) . '.123';
my $f = Math::BigFloat-new($str);
print $f;
print int($f);
my $i = Math::BigInt-new('654' x 12);
print $i;
print $i % 1000;
__END__
Outputs:
987987987987987987987987987987987987.123
987987987987987987987987987987987987
654654654654654654654654654654654654
654
#
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: cairo module 1.1 installs, but doesnt run...
- Original Message - From: Greg Aiken if it matters, i just installed the module using PPM gui to Perl 5.8.8 build 820 the module installed 'normally' without any errors being thrown, yet the test script failed immediately upon 'use Cairo'; I can't really answer the question you've asked, but there is a Cairo ppm package at the sisyphusion repo ( http://www.sisyphusion.tk/ppmindex.html ). The 5.8 package there was built using perl-5.8.9. This means that there's a possibility that it won't work with 5.8.9 - though I really don't know the likelihood of that being the case. (I fear it might produce exactly the same error with 5.8.8 and earlier, but you'd have to try it to be sure.) The Perl_hv_common symbol is to be found in the 5.8.9's perl58.dll, but I suspect it might be missing from 5.8.8's perl58.dll. (It's certainly missing from 5.8.0's perl58.dll.) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Why can't linker find CreateJobObjectA ?
- Original Message - From: Mark Dootson mark.doot...@znix.com To: Sisyphus sisyph...@optusnet.com.au Cc: perl-win32-users perl-win32-users@listserv.ActiveState.com Sent: Wednesday, March 14, 2012 1:14 AM Subject: Re: Why can't linker find CreateJobObjectA ? Hi, On 11/03/2012 23:52, Sisyphus wrote: An afterthought or two: It's a bug, right ? (It smells like a bug to me.) Is it a bug in perl ? I'm thinking that CORE/win32.h should be assigning the value associated with the actual OS on which perl is running, rather than just assigning the minimum supported value. Cheers, Rob I'm not so sure. Perl has to define the minimum it needs and it is really up to the coder to define the minimum they need. I think what Perl does is reasonable. Yeah, I'm still not sure either :-) It just seems odd to me that it's up to the coder to know about this and take appropriate action - especially in this day and age, when things are supposed to just work. And, I still find myself thinking that the CORE/win32. h assertion that _WIN32_WINNT == 0x0400 is just an out-and-out lie (on this Vista box). It certainly misleads the mingw.org (gcc-4.5.2) compiler. I think It would also be quite standard to put #define _WIN32_WINNT 0x0501 before any includes if you needed capability not included until XP. If Perl on Windows Vista defined a minimum of 0x0600 (or whatever it is) then anything compiled that linked to libperl would possibly not run on a Windows XP machine which would cause much more unexpected grief I think. The way things are, failures are up front at compilation time. If the person doing compilation needs an explicit win version, they are fully aware of the limits they are introducing. Done as #define _WIN32_WINNT = current platform would cause many more failures at end user time. On Windows, end users very often just get binaries. Those are fair points, I think. Perhaps they demonstrate that either: a) Windows users should be compiling themselves, rather than relying on pre-built binaries; or b) suppliers of binaries should be providing separate binaries for the different Windows flavours; but I really don't want to be the one who pushes *either* of those alternatives :-) For Inline::C you do of course want the opposite so I think your solution on Windows is to either prepend #define _WIN32_WINNT 0x0NNN to the code being compiled or pass a -D_WIN32_WINNT=0x0NNN to the compiler. Yes, it's actually the latter that's currently needed. The former still places the #define (too late) *after* the inclusion of perl.h - which is perhaps something that Inline::C ought to address. (I'm thinking Inline::C ought really provide some option that enables one to place C code *before* the inclusion of EXTERN.h, perl.h and XSUB.h in the generated XS file.) Thanks, Mark. I don't intend to pursue this bug any further - for now, at least. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Why can't linker find CreateJobObjectA ?
- Original Message - From: Mark Dootson So, I think you need an explicit #define _WIN32_WINNT 0x0501 and all should be OK Yes, that looks to be the fix. Many thanks, yet again, Mark ! (That's not the first time you've helped me out :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Why can't linker find CreateJobObjectA ?
- Original Message - From: Mark Dootson mark.doot...@znix.com To: Sisyphus sisyph...@optusnet.com.au Cc: perl-win32-users perl-win32-users@listserv.ActiveState.com Sent: Sunday, March 11, 2012 5:29 PM Subject: Re: Why can't linker find CreateJobObjectA ? Hi, Looked at Perl 5.12.1 and that has following in CORE\Win32.h #ifndef _WIN32_WINNT # define _WIN32_WINNT 0x0400 #endif In compilers that support windows versions below XP, the CreateJobObject definition will be wrapped in a #if _WIN32_WINNT = 0x0500 #endif block. So, I think you need an explicit #define _WIN32_WINNT 0x0501 and all should be OK An afterthought or two: It's a bug, right ? (It smells like a bug to me.) Is it a bug in perl ? I'm thinking that CORE/win32.h should be assigning the value associated with the actual OS on which perl is running, rather than just assigning the minimum supported value. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Why can't linker find CreateJobObjectA ?
Hi,
This is a win32-perl issue, but not specifically an *ActivePerl* issue.
For the demo, consider this Inline::C script:
###
use strict;
use Inline C = Config =
LIBS = '-lkernel32',
BUILD_NOISY = 1;
use Inline C = 'END_C';
#include windows.h
void foo( char *name ) {
int job;
job = CreateJobObjectA( NULL, name );
}
END_C
foo( 'fred' );
###
With perl-5.14.0 and the mingw port of gcc-4.5.2 there's no problem. (See
attached 'ok.txt'.)
With perl-5.12.0 and the *same* compiler, CreateJobObjectA doesn't get
found, even though it's defined in libkernel32.a (to which we are linking).
(See attached 'out.txt'.)
It's not a mingw-specific problem because I have a perl 5.10.0 that I built
using MSVC++ 7.0, and the same problem occurs there (see outVC7.txt).
With Microsoft Compilers only (even on a perl/compiler combo that works), we
additionally get the warning:
warning C4013: 'CreateJobObjectA' undefined; assuming extern returning int
Why does that happen ?
Generally, there's no problem with Inline::C and Windows API functions - but
the Job related functions (such as CreateObjectA, SetInformationJobObject
and AssignProcessToJobObject) just don't get found with some perl/compiler
combos.
(Btw, I haven't been able to re-create the failure on any of my x64 builds.)
Any ideas as to what might be screwing things up ? (I've spent hours
comparing outputs of working and non-working builds of the script, and
haven't been able to spot the crucial difference.)
Cheers,
Rob
validate Stage
Starting Build Preprocess Stage
get_maps Stage
Finished Build Preprocess Stage
Starting Build Parse Stage
Finished Build Parse Stage
Starting Build Glue 1 Stage
Finished Build Glue 1 Stage
Starting Build Glue 2 Stage
Finished Build Glue 2 Stage
Starting Build Glue 3 Stage
Finished Build Glue 3 Stage
Starting Build Compile Stage
Starting perl Makefile.PL Stage
Writing Makefile for job_pl_4a1d4
Finished perl Makefile.PL Stage
Starting make Stage
C:\MinGW\perl512\bin\perl.exe C:\MinGW\perl512\site\lib\ExtUtils\xsubpp -typemap
C:\MinGW\perl512\lib\ExtUtils\typemap -typemap C:\_32\pscrpt\inline\typemap job_pl_4a1d4.xs
job_pl_4a1d4.xsc C:\MinGW\perl512\bin\perl.exe -MExtUtils::Command -e mv -- job_pl_4a1d4.xsc
job_pl_4a1d4.c
gcc -c -IC:/_32/pscrpt/inline -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READFIX -s -O2 -DVERSION=\0.00\
-DXS_VERSION=\0.00\ -IC:\MinGW\perl512\lib\CORE job_pl_4a1d4.c
Running Mkbootstrap for job_pl_4a1d4 ()
C:\MinGW\perl512\bin\perl.exe -MExtUtils::Command -e chmod -- 644
job_pl_4a1d4.bs
C:\MinGW\perl512\bin\perl.exe -MExtUtils::Mksymlists \
-e Mksymlists('NAME'=\job_pl_4a1d4\, 'DLBASE' = 'job_pl_4a1d4', 'DL_FUNCS' = { },
'FUNCLIST' = [], 'IMPORTS' = { }, 'DL_VARS' = []);
dlltool --def job_pl_4a1d4.def --output-exp dll.exp
g++ -o blib\arch\auto\job_pl_4a1d4\job_pl_4a1d4.dll -Wl,--base-file -Wl,dll.base -mdll -s
-Lc:\MinGW\perl512\lib\CORE -LC:\MinGW\lib job_pl_4a1d4.o
-Wl,--image-base,0x1a03 C:\MinGW\perl512\lib\CORE\libperl511.a C:\MinGW\lib\libkernel32.a
C:\MinGW\lib\libmoldname.a C:\MinGW\lib\libkernel32.a C:\MinGW\lib\libuser32.a
C:\MinGW\lib\libgdi32.a C:\MinGW\lib\libwinspool.a C:\MinGW\lib\libcomdlg32.a
C:\MinGW\lib\libadvapi32.a C:\MinGW\lib\libshell32.a C:\MinGW\lib\libole32.a
C:\MinGW\lib\liboleaut32.a C:\MinGW\lib\libnetapi32.a C:\MinGW\lib\libuuid.a
C:\MinGW\lib\libws2_32.a C:\MinGW\lib\libmpr.a C:\MinGW\lib\libwinmm.a C:\MinGW\lib\libversion.a
C:\MinGW\lib\libodbc32.a C:\MinGW\lib\libodbccp32.a C:\MinGW\lib\libcomctl32.a dll.exp
job_pl_4a1d4.o:job_pl_4a1d4.c:(.text+0x15): undefined reference to
`CreateJobObjectA'
collect2: ld returned 1 exit status
dmake: Error code 129, while making
'blib\arch\auto\job_pl_4a1d4\job_pl_4a1d4.dll'
A problem was encountered while attempting to compile and install your Inline
C code. The command that failed was:
dmake
The build directory was:
C:\_32\pscrpt\inline\_Inline\build\job_pl_4a1d4
To debug the problem, cd to the build directory, and inspect the output files.
at job.pl line 5
BEGIN failed--compilation aborted at job.pl line 14.
validate Stage
Starting Build Preprocess Stage
get_maps Stage
Finished Build Preprocess Stage
Starting Build Parse Stage
Finished Build Parse Stage
Starting Build Glue 1 Stage
Finished Build Glue 1 Stage
Starting Build Glue 2 Stage
Finished Build Glue 2 Stage
Starting Build Glue 3 Stage
Finished Build Glue 3 Stage
Starting Build Compile Stage
Starting perl Makefile.PL Stage
Writing Makefile for job_pl_4a1d
Finished perl Makefile.PL Stage
Starting make Stage
Microsoft (R) Program Maintenance Utility Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.
C:\_32\perl_vc7\5.10.0\bin\perl.exe C:\_32\perl_vc7\5.10.0\lib\ExtUtils\xsubpp -typemap
Re: Making directories
- Original Message - From: Barry Brevik Does anyone have advice for me about how they create directories with Perl? I've used: system 'mkdir', $path; but check 'mkdir /?' to see if that approach is suitable for you. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Catalyst install possible via PPM?
- Original Message - From: Bill Cowan cow...@mindspring.com To: perl-win32-users@listserv.ActiveState.com Sent: Monday, September 19, 2011 12:35 PM Subject: Catalyst install possible via PPM? Have anyone been able to install Catalyst including set of useful modules/plugins? I haven't tried. The ActiveState repository only includes a few Catalyst plugins. Use another repository? That might work. See if adding the trouchelle repo helps: ppm repo add trouchelle I can see that Catalyst-5.7001 is available there for perl-5.12, along with its pre-requisite Catalyst::Runtime (version 5.80024 is on offer) Must I use Strawberry Perl to install a complete set of Catalyst modules? That's certainly another option to try - installing using CPAN.pm. Or, with ActivePerl, firstly 'ppm install MinGW', then you should get the same mileage as you'd get with Strawberry - installing using CPAN.pm. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: most powerful and amazing PDL + PGPLOT + GSL + OpenGL
- Original Message - From: Greg Aiken Does anyone in this list currently use PDL and PGPLOT? If so, I was wondering if I could ask you a question. Note that there's also support for PLplot (with the PDL ppm package available from http://www.sisyphusion.tk ) and there will soon be an add-on module (PDL-Graphics-Gnuplot) providing Gnuplot support. (Nothing wrong with using pgplot, of course.) I have basically figured out how to draw my own 2D graph. Basically, PGPLOT draws line segments to connect sample points. If one has a set of sample points, the closer they are to each other, the less 'line segmenty' the line looks - and the result is more like a smooth curve. I was wondering if anyone had an example that starts with a sparse X,Y sample set, and uses the GSL 'cspline' routine to 'make more closer spaced points', for the purpose of drawing a 'smoother' graph that takes on a cubic spline appearance. Best place to ask for this sort of assistance is on the perldl list. Subscribe by going to: http://mailman.jach.hawaii.edu/mailman/listinfo/perldl It's a quite active and helpful list. You probably already found it but, in case you haven't, the PDL home page is at http://pdl.perl.org/ Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: PPD for two modules?
- Original Message - From: Arms, Mike ma...@sandia.gov To: Perl-Win32-Users@listserv.ActiveState.com Sent: Tuesday, March 08, 2011 10:05 AM Subject: PPD for two modules? Hi, all. I am looking for PPD's for the following two modules compiled for ActivePerl v5.12.3: String-CRC (v1.0) - note: NOT String-CRC32 Time-modules(v2006.0814) I did not find them under the ActiveState, bribes, trouchelle, or uwinnipeg repositories. Anyone have a PPD source for them? === ppm repo add sisyphusion ppm install String-CRC ppm install Time-modules Note that Time-modules (which is a pure perl module) fails quite a lot of tests, complaining that they're being run in the wrong order. I suspect it's just a bug in the test script, but I haven't had time to check. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [Trivial Pursuit] Which Win32 perl was the first to be built with -Dusethreads ?
- Original Message -
From: Jan Dubois
$Config{usethreads} wasn't set correctly on Windows until 5.8.1:
http://perl5.git.perl.org/perl.git/commitdiff/7e0017d3
Does anyone here know if there were any pre-5.8.8 builds of ActivePerl
that
were built with -Dusethreads ?
It looks though that there has been an integration error in the early
ActivePerl 5.8 sources, and the value has been overwritten with undef
from the $Config{use5005threads} setting until ActivePerl 5.8.6.811.
Thanks for digging that up, Jan.
This all came about when I tried to build Language::Prolog::Yaswi using
perl-5.8.0 (build 806), and the 'perl Makefile.PL' process bailed out
because usethreads was undef. (I gather that ithreads is not a suitable
substitute in this instance.)
I noticed that both 5.8.8 and 5.8.9 defined usethreads, and became curious
about which build of ActivePerl would be the earliest one that would build
the module. Looks like the answer is 811 - though I gather that if I used
any of the builds that are later than 5.8.0 through to build 811 and amend
$Config{usethreads} appropriately, it might still work.
I don't really expect that I'll ever need to build L::P::Y for anything
earlier than perl-5.8.8 - but at least I now know the possibilities that
exist for earlier versions of 5.8.x should the need ever arise.
Mind you, I haven't even verified that L::P::Y does, in reality,
need -Dusethreads. But the module was written by Salvador Garcia and
he's usually very much on the ball.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
[Trivial Pursuit] Which Win32 perl was the first to be built with -Dusethreads ?
Hi, Earliest perl that I have that was built with -Dusethreads was a perl-5.8.8 that I built myself using MinGW ... but I don't have any perls between 5.8.0 (which was *not* built with -Dusethreads) and 5.8.8. Does anyone here know if there were any pre-5.8.8 builds of ActivePerl that were built with -Dusethreads ? Short of downloading the various builds of ActivePerl, how would I ascertain just which build of ActivePerl was the first to offer -Dusethreads ? I've tried looking at the changes-58.html file that ships with build 827. For anyone who knows precisely what to look for I suspect it answers my question ... but I don't know precisely what to look for :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Where's Tk?
- Original Message - From: Brian Raven bra...@nyx.com To: activep...@activestate.com; perl-win32-us...@activestate.com Sent: Friday, December 17, 2010 12:02 AM Subject: Where's Tk? I have Activestate Perl 5.12.2 (build 1202) installed. I can see some Tk extension packages in the PPM gui, but no sign of Tk itself. Is there a problem, or is just me looking in the wrong place? There's a ppm package for Tk-804.029 at the bribes repo. You should be able to grab it with: ppm repo add bribes then ppm install Tk Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32 modules crash over the network
- Original Message - From: Charles Manafa Subject: Win32 modules crash over the network Folks, I seem to be having difficulties loading any Win32 module, when Perl is executed from a remote server. I basically copied a working local Perl installation to a server, so it can be run from any machine. Other modules load fine, but Win32 modules seem to crash. The client PCs are XP running SP3. Any assistance will be greatly appreciated. === Do you get any meaningful error messages anywhere ? Of the non-Win32 modules that you've tried loading, have they all been pure-perl ? If so, try loading an extension - eg Devel::Peek (which uses XSLoader) and Digest::SHA (which uses DynaLoader). Can't really think of any reason that Win32 modules should be the only ones affected. Perhaps they all rely on some particular Windows dll(s) that none of the other modules need, and that there's some problem relating to the particular Windows dll(s) but nothing specific comes to mind. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Re: Net-SSH2 build process
Richie listm...@triad.rr.com wrote: On 10/29/2010 10:39 PM, Richie wrote: On 10/29/2010 9:13 PM, Richie wrote: I worked around it by adding C:\MinGW\bin to PATH for now. Are doing anything extra to incorporate a static gcc lib into the SSH2.dll? Forget about this question. I checked back on my other box and it doesn't see Sorry, I meant to say I checked back on my other box (premade msys) and it doesn't seem to have this issue :) Yes, I was a bit puzzled by that. I haven't been including libgcc_s_dw2-1.dll with any of my ppm packages because I believe it to be unnecessary. When I saw that you'd got that pop-up, however, I started to wonder Afaik, Net::SSH2, when built against a static libssh2, does not have any dependency on libgcc_s_dw2-1.dll - but there may be some caveats to that. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
Sisyphus sisyph...@optusnet.com.au wrote: - Original Message - From: Richie listm...@triad.rr.com collect2: ld returned 255 exit status -crashed here There have been problems with collect2 and mingw in the past. I would've thought they were fixed by the time 5.10 arrived, but perhaps not. (Otherwise I don't know what would be causing this.) Windows XP was not affected; Vista (pre SP1) was ... not sure about Windows 7. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
From: Richie
Just tried 5.12 portable. Had to use the following pieces, but it
worked
push @search_paths, 'C:/msys/1.0/local', 'C:/msys/1.0/local/ssl' ,
'C:/msys/1.0/mingw' (Makefile.PL)
set PATH=C:\msys\1.0\mingw\bin;%PATH% (strawberry shell)
Perhaps the extra search_paths element was needed due to additional
differences in our msys installs
What's in C:/msys/1.0/mingw ? (My msys/1.0/mingw is empty.)
I need to specify 'C:/msys/1.0/local' and 'C:/msys/1.0/local/ssl' as that's
where openssl and zlib are for me.
However, some (most ?) people put their libraries into /mingw by making use of
the --prefix argument. That way msys finds them by default.
I guess therefore that, on your machine, there are some libraries in /mingw
that are needed to build Net::SSH2 - whereas, on my machine, all of those
libraries are in /usr/local. That should be the only difference.
Good that Strawberry are finally including Net::SSH2 in their distro.
While I think of it - I've found it necessary to apply this patch to SSH2.pm
(version 0.33):
#
--- C:\perl5121_M/site/lib/Net/SSH2.pm_orig Mon Aug 23 20:06:32 2010
+++ C:\perl5121_M/site/lib/Net/SSH2.pm Mon Aug 23 20:36:30 2010
@@ -373,8 +373,18 @@
$self-error(0, want $block, have $count), return
unless $count == $block;
die 'sysread mismatch' unless length $buf == $count;
- $self-error(0, error writing $count bytes to channel), return
- unless $chan-write($buf) == $count;
+ my $wrote = 0;
+ while ($wrote = 0 $wrote $count) {
+ my $wr = $chan-write($buf);
+ last if $wr 0;
+ $wrote += $wr;
+ $buf = substr $buf, $wr;
+ }
+ unless($wrote == $count) {
+ my @error = $self-error();
+ warn Error writing $count bytes to channel: @error\n;
+ return;
+ }
}
# send/receive SCP acknowledgement
#
See
https://rt.cpan.org/Public/Bug/Display.html?id=59332
for the discussion about it. (If you're not going to use scp it probably
doesn't matter.)
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
- Original Message - From: Richie I'm not sure about this. My msys doesn't seem to find all those mingw includes by default. On checking, it looks like I could be mistaken about that. I was basing that statement on the wiki at http://www.mingw.org/wiki/MSYS : # To install 3rd party library and applications which uses the autotools build system the following commands are often used. ./configure --prefix=/mingw make make install Installing to /usr/local should be avoided, since the MinGW compiler won't look there by default. # Maybe /mingw is not the same as msys/1.0/mingw ... perhaps it's someplace else in the msys tree. Anyway, I've always just let stuff go into /usr/local. Besides, if one wants the stuff in /usr/local to be found by default one could just set the CPATH and LIBRARY_PATH environment variables appropriately: export CPATH=/usr/local/include:/usr/local/ssl/include export LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib /usr/local exists until I started make install'ing stuff. Is it possible that you have a mount? I may try to install it according to the wiki again but it was so 'piece meal' that when I discovered a premade I used that instead. If it's working ok (and it sounds like it is), I would happily leave it be. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
- Original Message - From: Richie listm...@triad.rr.com To: Sisyphus sisyph...@optusnet.com.au Cc: perl-win32-users@listserv.ActiveState.com Sent: Thursday, October 28, 2010 2:08 AM Subject: Re: Net-SSH2 build process On 10/27/2010 2:31 AM, Sisyphus wrote: (Btw, the ppm packages for Net-SSH2-0.33 available from the uwinnipeg repo should work fine with Strawberry Perl ... but I take it you already know that.) Cheers, Rob Thanks for the information. Anyway, I've come to rely on this functionality on both Windows and Solaris and so far you seem to be the only one that provides a packaged solution on Windows. Serguei Trouchelle used to provide Net::SSH2 on his ppm repo - built using MSVC++ and the Makefile provided in the win32 folder of the libssh2 source distro (I think). You could (as yet another alternative) take a look at the win32/Makefile.win32 and see if it offers any joy for you - I haven't tried it. Anyway, under more extensive testing, there was a problem with Serguei's build, so he took it off the repo. (The actual problem was that the test script that ships with Net::SSH2 segfaulted after test 28 was run. The problem may since have been fixed faik.) I wanted to learn how to do it just in case :) I'm actually new to cygwin, but already use msysgit, so I think I will switch to use a full install of msys. Yes, msys is *my* preferred option. (I use cygwin pretty much only for its 'git' and 'svn' clients :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
- Original Message - From: Richie listm...@triad.rr.com Here are some notes so far (and failures). On Solaris I had to build shared libs to avoid this issue, but shared seems to be more problematic though. Are you using gcc 4.5 and source versions of these packages comparable to what I'm attempting to compile? I've successfully used both 3.4.5 and 4.6.0 - 4.5 should be fine. As regards my version of MSYS: $ uname -a MINGW32_NT-6.0 DESKTOP2 1.0.11(0.46/3/2) 2007-07-29 17:16 i686 unknown The libssh2 failure in your attachment arises because libssh2.a has been statically built (probably because openssl is static, as you suspected) but then the process still goes looking for dynamic symbols (the '_imp__' prefix). Usually there's a message about this in the build output (before the library gets built). I don't have a dynamic build of openssl, though I think I've probably tried in the past. I'll give it another go later today and see if I can get anywhere. I'm fairly sure you'll need a dynamic openssl to build a dynamic libssh2. (The Strawberry build of openssl may be usable here if all else fails.) If you decide that a static build of libssh2 will suffice, first run 'make distclean', then : ## In the configure script, change: case $host in *-mingw*) CFLAGS=$CFLAGS -DLIBSSH2_WIN32 -DWINSOCK_VERSION=0x0200 LIBS=$LIBS -lws2_32 ;; to: case $host in *-mingw*) CFLAGS=$CFLAGS -DWINSOCK_VERSION=0x0200 LIBS=$LIBS -lws2_32 -lgdi32 ;; ## (That is, remove the '-DLIBSSH2_WIN32' and add the '-lgdi32'.) Then (obviously) re-run ./configure with the static and shared args reversed , 'make', 'make check' and 'make install'. Attached is the Net::SSH2 Makefile.PL that I then use to build the module against the static libssh2 library. It contains some hard coded paths (to msys headers and libraries) which may well be the same as on your machine or might not. Modify those as needed and you should be right. (It would, of course, be good to be able to also build a libssh2 *dll* - so I'll put a bit of effort into that as time permits. I expect that the reason I don't already have one somewhere is that I didn't succeed in building openssl shared libs.) Cheers, Rob Makefile.PL Description: Binary data ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
- Original Message - From: Richie listm...@triad.rr.com (using: push @search_paths, 'C:/msys/1.0/local', 'C:/msys/1.0/local/ssl') - i don't expect dmake to work but tried it anyway in strawberry shell, see attached file test1.txt It should work. (No problem for me on Strawberry 5.12.0.1.) Looking at test1.txt it seems that there's a pre-existing build. Could you run 'dmake realclean', and then try again. (Post the 'dmake' results again if it still fails.) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
- Original Message - From: Sisyphus sisyph...@optusnet.com.au It should work. (No problem for me on Strawberry 5.12.0.1.) Looking at test1.txt it seems that there's a pre-existing build. Could you run 'dmake realclean', and then try again. (Post the 'dmake' results again if it still fails.) Aaah ... found a Strawberry 5.10 installation and I get the same error as you reported. Might need to use the same compiler both with Strawberry 5.10 and to build libssh2. (Doesn't seem to matter with 5.12.) Can you alter your Strawberry path so that the mingw installation that built libssh2 is found *instead* of the mingw installation that ships with Strawberry ? That did the trick for me on Strawberry 5.10: set PATH=C:\mingw\bin;%PATH% (or whatever) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net-SSH2 build process
- Original Message - From: Richie ric...@triad.rr.com To: Sisyphus sisyph...@optusnet.com.au Cc: perl-win32-users@listserv.ActiveState.com Sent: Wednesday, October 27, 2010 6:31 AM Subject: Net-SSH2 build process I'd like to get Net::SSH2 to build on strawberry perl 5.10 but ran into SSH2.dll build issues as expected. Do you mind sharing any of your notes regarding this? Maybe you have accomplished this yourself? I'm guessing that you might use cygwin to build the SSH2.dll. Thanks for any information. I actually build in the msys shell, and I build only a *static* libssh2 library. There's a couple of minor changes that I first have to make to the 'configure' script that's in the top level source folder - those changes would not need to be made when building a libssh2 dll. The command I run is: ./configure --disable-shared --enable-static CPPFLAGS=-I/usr/local/include -I/usr/local/ssl/include LDFLAGS=-L/usr/local/lib -L/usr/local/ssl/lib make make check make install I could also do that as a cross-compilation in Cygwin, in which case the following switches would need to be added to the 'configure' command (ie before ' make ...'): --host=i686-pc-mingw32 --build=i686-pc-cygwin CC='gcc -mno-cygwin' host_alias=i686-pc-mingw32 Actually, I'm not sure that *all* of those additional switches are, in fact, needed - but that's what I add when I build for MinGW in the Cygwin shell, and it has worked quite well on the few occasions I've tried it. (Haven't actually tried it with libssh2, however.) The 'CPPFLAGS' and 'LDFLAGS' arguments would need to be changed - unless I had mingw-compatible zlib openssl headers and libraries in the locations specified. If you're building a dll, then '--disable-shared --enable-static' needs to become '--disable-static --enable-shared'. As a cross-compilation, 'make check' won't work, so you'd delete that bit if building for MinGW under Cygwin. Also you'd need to specify the location where you want 'make install' to install the files - as you presumably wouldn't want them to go into Cygwin's /usr/local (which is where they would go by default). For that you'd add the confgure switch: --prefix=/cygdrive/c/wherever For a dll, you'll need openssl and zlib dll's to be locatable (and to have names that the Cygwin build process recognises ... whatever they may be). You might not need to specify 'CPPFLAGS' and 'LDFLAGS' switches (not sure). The openssl and libz that I use are also static, and were built in the msys shell in a similar way to libssh2. So ... decide how you want to go about it static or dynamic ? ... cygwin or msys ? Then give it a crack, and see how it goes. I have Strawberry 5.12.0.1 (but not 5.10), so I can probably emulate whatever you do and (hopefully) then help out if you strike trouble. (Btw, the ppm packages for Net-SSH2-0.33 available from the uwinnipeg repo should work fine with Strawberry Perl ... but I take it you already know that.) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Using mingw64 with x64 ActiveState builds.
- Original Message - From: Mark Dootson mark.doot...@znix.com To: Sisyphus sisyph...@optusnet.com.au Cc: perl-win32-users perl-win32-users@listserv.ActiveState.com Sent: Wednesday, April 21, 2010 12:12 PM Subject: Re: Using mingw64 with x64 ActiveState builds. Hi, I don't know why missing the '-s' flag from the linker causes failures. I do know that when the '-s' flag is specified, there's no symbol table in the dll PE image and no need for associated relocation addresses. The gcc debugging symbols are for most practical purposes useless with ActivePerl I would think. So having '-s' as a standard option isn't a bad thing in itself. It would be nice to understand exactly what is happening though and therefore rule out the possibility of any other problems. For info, I have tried the 32bit version of mingw-w64 and the debugging symbols cause no difficulty there. I've checked the PE/COFF headers for both 32bit and 64bit DLL's - and the 32 bit version definitely includes debugging symbols if you don't specify -s - and still works. The 64bit DLL must be a valid PE+ (64bit) image, or it would not load at all I would not think. Anyhow, I combined the flags in your Config.pm file together with details from the Config_heavy.pl produced when Perl itself is compiled with mingw gcc and put it in my Config_w64.pm. I've attached that again for the list's sake as the original was missing a couple of probably important options (already in yours and the AS versions). Interestingly, the Config_heavy.pl produced when Perl itself is compiled with mingw gcc includes the '-s' flag in the ldflags, and also in optimize - 'optimize' = '-s -O2'. (I'm assuming it has the same meaning here). For info, the problem may be a symbol name mangling issue. I noticed in the 64 bit PE that some symbol names had been mangled ( e.g _function becomes _funct...@12 ) but far fewer than in the 32bit PE. My brief Googling suggests that the 64 bit symbols should not be mangled / decorated in this way at all - but I don't really know. Thanks very much for all of that. I, too, an quite puzzled as to why the '-s' should be making such a difference and I'll try to do some investigating of my own when I get a chance. (Please share any future enlightenments that you might have regarding this with me :-) For mine - I'll now go back to my original approach (yes, even the PERL_ARCHIVE hack that produces linking to the perl dll). Of course, I'll also be including '-s' flag as already discussed - and I've added '-s' to optimize, too - just in case. I'll see how that goes over time, and revert to linking to libperl512.a if the need arises. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Using mingw64 with x64 ActiveState builds.
- Original Message - From: Mark Dootson mark.doot...@znix.com To: Sisyphus sisyph...@optusnet.com.au Cc: perl-win32-users perl-win32-users@listserv.ActiveState.com Sent: Monday, April 19, 2010 10:59 PM Subject: Re: Using mingw64 with x64 ActiveState builds. Hi, Did as you suggested and yes, I get same failures as you starting in 01syntax.t I had a look at differences in config output as your symptom of not being able to load more than one Math:: library at once sounded like maybe a linker error with msvcrt? Anyhow, adding '-s' flag to linker options in your Config.pm seems to solve 'Inline' building errors _override(lddlflags, join( , -s -mdll, @libpaths)); _override(ldflags, join( , '-s', @libpaths)); Yes, that's it brilliant !!! ...and many thanks!!. (Fixes the problem with the Math:: modules, too.) Do you know why the absence of the '-s' flag does not have similarly disastrous consequences with the 32-bit ActiveState builds of perl and mingw32 ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Using mingw64 with x64 ActiveState builds.
Hi, For quite some time, ActivePerl users have been able to use mingw32/dmake seamlessly with x86 builds of ActivePerl. Many here will already be aware of that. However, the same is not true of the x64 ActiveState builds - attempting to use mingw64/dmake with them fails. One of the things with mingw64 is that there are 2 possible nomenclatures. If you download the builds made available by sezero, the various executables (gcc, g++, ar, dlltool, etc.) are named simply gcc.exe, g++.exe, ar.exe, dlltool.exe, etc. (as per usual). But then there's sometimes [1] an additional distro (in the order of ~200Mb) available from the same vendor ( http://sourceforge.net/projects/mingw-w64/files/ ) where the names of all of those executables is prefixed with 'x86_64-w64-mingw32-'. This arises, apparently, from the fact that these binaries are created as a cross-compilation - and the compiler itself is referred to as a cross-compiler. I don't understand that aspect very well what I do understand is that, whichever distro we use, it will be equally serviceable - for starters, both versions of the compiler will build perl-5.12.0 on windows. Strawberry Perl have chosen to use sezero's builds - I've been getting good results with the cross-compiler and seem to prefer it (but for no good reason, afaict :-) Anyway, the attached patches to lib/ExtUtils/MM_Win32 and lib/ActivePerl/Config.pm enable the x64 builds of ActivePerl to work with both of these mingw64 compilers (and dmake) ... but there's a catch there are still problems with using mingw64 with ActivePerl. Just build Inline::C and you'll see what I mean. If there's more than one section of C code in the Inline::C script (as is the case with some of the test scripts) then you'll get bizarre load_file:%1 is not a valid Win32 application at errors from DynaLoader from the subsequent sections. (Afaict, if there's only one section of C code, as is generally the case, then there's no problems with Inline::C). However, it goes even further than Inline::C. I can successfully build, test, and install Math::GMPz, Math::GMPq and Math::GMPf on x64 build 1200 using mingw64 and dmake ... but if I try to load (use/require) more than one of those modules in the same script, the first loads ok but the other ones croak with that DynaLoader error. The order in which I try to load them doesn't matter - the first will succeed, the next will cause the fatal load error. Other perl extensions seem to be ok ... eg, no such problems with Math::GMP, much to my chagrin. I really would like to know what's going on here. I think I had similar issues when I first tried building perl (32-bit) using the mingw port of gcc-4.x.x, but thankfully they went away as gcc-4.x.x matured. (Note that mingw64 is gcc-4.4.4.) And there's no such problem with these mingw64 compilers if they're the compiler that actually built perl. It's just when I try to use these compilers with x64 builds of ActivePerl that the strange DynaLoader errors can eventuate. So ... do I file a bugzilla bug report at ActiveState and provide those patches ? If mingw64 is ever going to work with the x64 builds of ActivePerl, then something like them will be needed. (If the descision to exclusively use sezero's builds was made, then those patches could be simplified - there's currently a fair amount of kludge in them just to accommodate the possibility of the 'x86_64-w64-mingw32-' prefix.) Or do we decide that mingw64 will never work satisfactorily with the x64 builds of ActivePerl and just forget about it ? Or do we decide that, since the compiler that built the x64 ActivePerls is freely available (unlike the compiler that builds the x86 versions), then there's not even any need to have the x64 builds work with mingw64 ? Previous experience tells me that, in any event, Schwern is unlikely to ever apply my MM_Win32.pm patch - but I think ActiveState now use their own version of ExtUtils::MakeMaker. (ActivePerl/Config.pm is, afaik, outside of Schwern's jurisdiction :-) Cheers, Rob [1] These other distros used to be the norm, but they now seem to be available only spasmodically. I asked about this on the mingw64 mailing list a while back, and was told that there were temporary problems with these builds. (For some definition of temporary, no doubt ;-) MM_Win32.patch Description: Binary data Config.patch Description: Binary data ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Using mingw64 with x64 ActiveState builds.
- Original Message - From: Mark Dootson mark.doot...@znix.com I build using ExtUtils::FakeConfig and my own Config_w64.pm I've used that before with the x86 builds, back in the days when it was the only way to be able to use mingw with ActivePerl. It's very good - in fact I still use it to build some 5.8.x ppm packages on ActivePerl-5.8.0 (as that build of perl pre-dates ActiveState's automatic integration of mingw). Inline builds OK for me with this setup - the only test failure is in the taint tests. I've never figured out precisely why (taint tests always fail - not just the ones in Inline) but have just assumed its either PERL5OPT=-MConfig_w64 or the setting of @INC do in my sitecustomize.pl Excellent ! - it's encouraging to know that the glitches I've come up against *aren't* inevitable. I install ExtUtils::FakeConfig and ensure it creates libperl5xx.a during the 'dmake install' step. Interestingly, the creation of libperl5xx.a is not necessary with all-but-ancient versions of 32-bit gcc, as the recent versions (beginning with gcc-3.0.0, I think) are quite capable of linking to perl5xx.lib. However, that seems to be the case only with the x86 builds. With x64 builds, mingw64 is again unable to link to perl5xx.lib - so, again, we find the need to create a libperl5xx.a. Actually, in my patches, I've simply linked to perl5xx.dll instead of creating a libperl5xx.a. Jan will probably choke when he gets to that bit ... and I wonder if it might be the source of the strangeness I encountered. (Won't be hard to check if that *is* the culprit.) You could then maybe see if this approach works and it would help in tracking down your test failures. Definitely - hopefully I can find time to get onto this today. Thanks muchly for your thoughts - and for sending the config file. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Using mingw64 with x64 ActiveState builds.
- Original Message -
From: Jan Dubois j...@activestate.com
I'll eventually take a look at this, but for now have considered mingw-w64
to be too experimental to spend any time on it.
Yes, until recently I have also felt them to be too experimental - but
they've become much more solid in the last few months.
Note that you always had access to a free 64-bit compiler by downloading
the Windows 2003 R2 Platform SDK (hich actually is even the compiler used
to build ActivePerl 64-bit itself, due to it linking to the 64-bit version
of MSVCRT.dll and not a compiler version specific one like MSVCR80.dll).
Yes, I acknowledged that (in a roundabout way) a little further on in my
post.
I have that compiler and have been using it for quite some time with good
results. IIRC (and I may be wrong here as I haven't checked recently), the
trouble is that I can't get it to build some of the third party libraries
that I play around with - nor can I get it to link to those libraries if
they've been built with mingw64.
So, I think there's a niche there for the mingw64/ActivePerl combo.
I'm fine with making the modules as flexible as possible, even though
the PPM package for MinGW will most likely choose the smaller package,
which I assume has the more standard names.
I think that's the way to go - and it's the path that Strawberry Perl have
chosen. It's a much smaller download (~50Mb versus ~200Mb). Not sure if it
comes with gfortran, but I would think it lacks java, ada and other stuff -
none of which is necessary anyway. (Having gfortran might be handy - though
all of the fortran stuff in perl extensions still seems to need g77, which
is unavailable with gcc-4.x.x.)
Don't forget that I do have commit access to ExtUtils::MakeMaker too:
http://www.mail-archive.com/makema...@perl.org/msg02880.html
I just don't want to commit anything that will need to be reverted or
fixed in a short while, so I'm waiting until we have figured out exactly
how this should work.
Good - I think the Config.pm changes are ok but there's one thing in the
MM_Win32.pm patch that's very worthy of caution - namely the messing around
with $self-{PERL_ARCHIVE}.
It's there simply to force the compiler to link to the perl dll (as it can't
link to perl5xx.lib). A better solution might be for ActiveState to supply a
perl5xx.a. Now that Mark has verified that the glitches I've struck aren't
inevitable, we conclude that I'm doing something wrong - and what better
candidate is there than messing with PERL_ARCHIVE ? (I hope to sort that out
today ... if I can just stop writing emails :-)
It is my goal to reduce the remaining local changes in modules bundled
by ActivePerl to the bare minimum necessary, and ideally to no changes
at all for any modules that are on CPAN and can therefore be updated
via PPM or any of the CPAN shells.
Yes - I think I've been bitten in the past by having updated EU::MM on
ActivePerl. I now make sure that I stick with the version of EU::MM that was
shipped.
Thanks Jan.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Using mingw64 with x64 ActiveState builds.
- Original Message - From: Sisyphus sisyph...@optusnet.com.au You could then maybe see if this approach works and it would help in tracking down your test failures. Definitely - hopefully I can find time to get onto this today. Yes - everything seems fine with EU::FC, though I've not yet tracked down the source of the DynaLoader failures. As soon as I had installed EU::FC I modified my ActivePerl alterations to use the libperl512.a that EU::FC had built and installed. I was hoping that would be sufficient to eradicate the failures I had been getting, but no such luck - still those same damned DynaLoader errors. However, as soon as I set PERL5OPT to -MConfig_w64 everything goes fine. I'm hard pressed to understand how there's any siginificant difference between the 2 approaches (now that they're both linking to the same libperl512.a). Iff you're interested iff you have the time, I'm curious to know what happens if you: 1) unset PERL5OPT (so that EU::FC does not get involved) 2) rename lib/ActivePerl/Config.pm to Config.pm_orig (or somesuch) 3) install the attached Config.pm_new in lib/ActivePerl and rename it to Config.pm 4) then try to build Inline. (Maybe first check that 'perl-V:make', 'perl -V:libperl' and perl -V:cc' are reporting correct values.) You should then see the same failures as I've been getting (and that would ease my mind a little as to my own sanity :-) The first such failure should occur when the C/t/01syntax.t script is run. (No need for you to make any alterations to your MM_Win32.pm.) After you've finished, just reset PERL5OPT and restore the original lib/ActivePerl/Config.pm - and you're back to where you started from. Also, if you (or anyone else) have any ideas as to why one approach (EU::FC) is working for me, but the other isn't, I'd be interested to hear them. Cheers, Rob Config.pm_new Description: Binary data ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Upgrading to ActiveSate 5.10.1
- Original Message - From: Andrew Black andrewdbl...@googlemail.com One thing that concerns me about installing to the same place - what happens to modules that you have isntalled in site but now are in perl. WIll you end up with both. autodie (became core in 5.10.1) is an obvious case, are there others Yes - that could be a nuisance. You would end up with autodie in both perl/site/lib and perl/lib - and use autodie; would cause Perl to load the autodie that's in perl/site/lib (as that directory comes before perl/lib in @INC). This could be worked around, but if you weren't aware of what was happening, it might lead to some head scratching. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Upgrading to ActiveSate 5.10.1
- Original Message - From: Andrew Black andrewdbl...@googlemail.com To: perl-win32-users@listserv.ActiveState.com Sent: Wednesday, April 07, 2010 8:33 PM Subject: Upgrading to ActiveSate 5.10.1 I am thinking of upgrading my personal machine to use 5.10.1 - are there any gotachas I should be aware off. In particular, do module packages in 5.10 repostiory work with 5.10.1 Yep - the packages in the 5.10 repository work fine with 5.10.1. There could be some rare exceptions ... such as those modules that do offbeat things - eg PAR::Packer. Just install 5.10.1 over the top of the existing 5.10.0 installation, and you'll find that those packages you've already installed still work fine - no need to reinstall them. Be aware that 5.12.0 is just a matter of a few days away, though I don't see that as any reason to defer upgrading to 5.10.1. (When 5.12.0 does arrive, it will need its own repository - ie the 5.10 packages won't work with 5.12.) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: perl error message
- Original Message - From: Geoff Horsnell ge...@horsnell.freeserve.co.uk I have just downloaded and installed Perl 5.8.9 for Win32. When I try to compile a binary, I get the following error message. Use of uninitialized value in numeric eq (==) at /C:\Program Files\ActiveState Perl Dev Kit 7.3\bin\lib\pdklib.dllPDK/Util.pm line 147. That's just a warning ... it may or may not indicate a problem. Win32::BuildNumber not consistent with perl -v If I check Win32::BuildNumber, I get the following: C:\_32perl -wle print Win32::BuildNumber 825 and, if I run 'perl -v' I get: C:\_32perl -v This is perl, v5.8.9 built for MSWin32-x86-multi-thread (with 9 registered patches, see perl -V for more detail) Copyright 1987-2008, Larry Wall Binary build 825 [288577] provided by ActiveState http://www.ActiveState.com Built Dec 14 2008 21:07:41 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Note that in both cases the same build number (825) is quoted. The message you're getting suggests that Win32::BuildNumber and perl -v are reporting different numbers. Are they ? If so, then you've got a problem with multiple versions of perl and there's something seriously wrong with your perl installation or environment settings. If not, then I don't know what the message is about :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Build 1006 has some unexpected Config values
Hi,
With build 1006, I'm getting the following:
#
C:\_32perl -V:cc
Set up gcc environment - 3.4.5 (mingw-vista special r3)
cc='C:/_32/ap1005/site/bin/gcc.exe';
C:\_32perl -V:ld
Set up gcc environment - 3.4.5 (mingw-vista special r3)
ld='C:\_32\ap1005\site\bin\g++.exe';
C:\_32perl -V:make
make='C:\_32\ap1005\site\bin\dmake.exe';
C:\_32
#
Is it acceptable to have those Config values specify the full path and
extension ?
This prevents Inline::C from building as C:/_32/ap1005/site/bin/gcc.exe.exe
(which, of course, doesn't exist) can't be found by the C/Makefile.PL. And
I'm sure I've written the odd Makefile.PL or two where I've done something
like:
if($Config{make} eq 'dmake') {
# do something
}
That will now have to be rewritten as:
if($Config{make} =~ /dmake/) {
# do something
}
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Build 1006 has some unexpected Config values
- Original Message -
From: Jan Dubois j...@activestate.com
Is it acceptable to have those Config values specify the full path and
extension ?
Acceptable by whom? :) The documentation doesn't really say one way or
the
other:
| cc (cc.U):
| This variable holds the name of a command to execute a C compiler which
| can resolve multiple global references that happen to have the same
| name. Usual values are 'cc' and 'gcc'.
| Fervent ANSI compilers may be called 'c89'. AIX has xlc.
That's what I was wondering. If it's not prohibited, then it's permitted :-)
This prevents Inline::C from building as
C:/_32/ap1005/site/bin/gcc.exe.exe
(which, of course, doesn't exist) can't be found by the C/Makefile.PL.
Would you mind filing a bug report for it?
Shall do - along with a patch.
ExtUtils::MM_Win32 uses this mechanism:
sub is_make_type {
my($self, $type) = @_;
return !! ($self-make =~ /\b$type(?:\.exe)?$/);
}
I'll probably just do
if($Config{make} =~ /\bdmake/i) { ... }
(I think it's only 5 files in PDL that need the amendment.)
Thanks Jan.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ActiveState announces ActivePerl 5.10.1 build 1006
- Original Message - From: Jan Dubois j...@activestate.com To: activep...@listserv.activestate.com; perl-win32-users@listserv.ActiveState.com; mac...@perl.org Sent: Friday, August 28, 2009 9:17 AM Subject: ActiveState announces ActivePerl 5.10.1 build 1006 ActiveState is pleased to announce ActivePerl 5.10.1 build 1006, a complete, ready-to-install Perl distribution for Windows, Mac OS X, Linux, Solaris, and AIX. There's apparently a (presumably) minor bug with the Windows x64 build (msi package only) that came to light in the perlmonks thread http://www.perlmonks.org/index.pl?node_id=791470 . It's reported there that the 'perl -V' output begins with Summary of my perl5 (revision 5 version 10 subversion 0) which is the wrong subversion number. I installed from the zip package, and it correctly states the subversion number as '1'. Not sure what's going on there ... rather strange. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Determining Vista Editions
- Original Message - From: Michael Cohen mico...@us.ibm.com I have been using the Win32::GetOSVersion() function for many years in order to pull the Windows OS level. However, I now have a new need to determine whether or not the OS is Windows Vista Home Basic (or for that matter, other various editions). I do not see how to pull that information from GetOSVersion(). From what I can find on the web, I somehow need to use the GetProductInfo call from the kernel32 DLL. I have Windows Vista, but my kernel32 apparently does not have GetProductInfo(). Any attempt to access the function using Inline::C fails because GetProductInfo is not defined - ultimately it's an undefined symbol. If the function aint there, then it doesn't matter whether you use Inline::C or Win32::API - it's simply not going to work. Anyone know the exact situations under which this function becomes available ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: 2 MinGW-related feature requests.
- Original Message - From: Jan Dubois j...@activestate.com However, when you have C:\MinGW\bin in your PATH, then it would add C:\MinGW\lib, which is where all the libfoo.a import libraries for the standard Windows libraries are stored. Adding this directory gets rid of these warnings: Note (probably harmless): No library found for -lkernel32 Note (probably harmless): No library found for -luser32 Note (probably harmless): No library found for -lgdi32 Note (probably harmless): No library found for -lwinspool Note (probably harmless): No library found for -lcomdlg32 Note (probably harmless): No library found for -ladvapi32 Note (probably harmless): No library found for -lshell32 . . Note (probably harmless): No library found for -lmsvcrt At least for modules using Module::Install, like Par-Packer. The warnings are harmless, but it seems better to suppress them than to confuse a user that something might be wrong when actually it isn't. I see - I think that's a good enough reason to be doing this. I guess I'll need to add some more code to ActivePerl::Config to replace Perl\site\lib with Perl\site\lib\auto\MinGW\lib. So any objections to appending that location to LIBRARY_PATH? None. PS: MinGW-5.1.4.1 seems to be on the external PPM servers now if you want to give it a try. Thanks - I'll have a play with it later tonight. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: 2 MinGW-related feature requests.
- Original Message - From: Jan Dubois j...@activestate.com To: 'Sisyphus' sisyph...@optusnet.com.au; 'perl-win32-users' perl-win32-users@listserv.ActiveState.com Sent: Monday, July 13, 2009 4:07 AM Subject: RE: 2 MinGW-related feature requests. On Sun, 12 Jul 2009, Sisyphus wrote: Should I submit the 2 proposals below to bugzilla ? Yes, please! Done. Thanks Jan. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: 2 MinGW-related feature requests.
- Original Message -
From: Jan Dubois j...@activestate.com
I've built a new MinGW package 5.1.4.1 for PPM that includes the forwarder
for windres.exe.
I found a somewhat surprising WTF in the MinGW installer itself: even
though
the version number is unchanged at 5.1.4 the following 3 included packages
have been updated from the last time I downloaded it:
from: binutils-2.17.50-20060824-1.tar.gz
to: binutils-2.19.1-mingw32-bin.tar.gz
from: mingwrt-3.15.1-mingw32.tar.gz
to: mingwrt-3.15.2-mingw32-dev.tar.gz
from: w32api-3.12-mingw32-dev.tar.gz
to: w32api-3.13-mingw32-dev.tar.gz
If you have any contact with the MinGW developers you may want to mention
that updating the version number of MinGW might be a good idea. I would
have expected that at least the Build number would be changed in the
mingw.ini file, but even that remained at 11.
I don't really have much input into MinGW (lack of tuits), but I do post
there occasionally, and am still subscribed to the users list. I'll raise
this with them and give you a brief summary of their position on this.
The 5.1.4.1 PPM package will have all the latest bits, so you may want
to give it a spin. It may take a day or two before it becomes visible on
the external PPM server.
I'll download it in a day or two, and check that it's fine. (I'm sure it
will be.)
I've added that code, and also tried to use it for the ActivePerl::Config
hack that tells ExtUtils::Liblist::Kids about the MinGW library location:
--- lib/ActivePerl/Config.pm.~1~ Sun Jul 12 23:50:01 2009
+++ lib/ActivePerl/Config.pm Sun Jul 12 23:50:01 2009
@@ -86,7 +86,15 @@
# assume MinGW or similar is available
$gcc =~ s,\\,/,g;
my($mingw) = $gcc =~ m,^(.*)/bin/gcc\.exe$,;
- $ENV{ACTIVEPERL_MINGW} = $mingw if defined $mingw;
+ if (defined $mingw) {
+ $mingw .= /lib;
+ if (defined $ENV{LIBRARY_PATH}) {
+ $ENV{LIBRARY_PATH} .= ;$mingw;
+ }
+ else {
+ $ENV{LIBRARY_PATH} = $mingw;
+ }
+ }
_override(cc, gcc);
_override(ccname, gcc);
I haven't struck a need to make the above amendment - but I've just tested
it now and the application of that patch doesn't seem to break anything.
--- lib/ExtUtils/Liblist/Kid.pm.~1~ Sun Jul 12 23:50:01 2009
+++ lib/ExtUtils/Liblist/Kid.pm Sun Jul 12 23:50:01 2009
@@ -272,8 +272,8 @@
if ($VC and exists $ENV{LIB} and $ENV{LIB}) {
push @libpath, split /;/, $ENV{LIB};
}
-if ($GC and exists $ENV{ACTIVEPERL_MINGW} and $ENV{ACTIVEPERL_MINGW})
{
-push @libpath, $ENV{ACTIVEPERL_MINGW}/lib;
+if ($GC and exists $ENV{LIBRARY_PATH} and $ENV{LIBRARY_PATH}) {
+push @libpath, split /;/, $ENV{LIBRARY_PATH};
}
foreach (Text::ParseWords::quotewords('\s+', 0, $potential_libs)){
Again, I've struck no need to remove the additional 2 lines that you have,
but again, the application of that patch doesn't break anything.
I don't know why $ENV{ACTIVEPERL_MINGW}/lib was being pushed onto @libpath
in the first place. For me, that resolves to my perl/site/lib directory and
there's certainly no reason for me to push that location onto @libpath. Did
it ever serve a purpose for anyone ?
This should make it easier to eventually get the changes back into the
CPAN
version. Do you see any problem with pushing the MinGW/lib directory to
the end of LIBRARY_PATH even though GCC will already have this location
built in?
For me, there's no problem with that - as I said above, it's merely my
perl/site/lib folder that's being added to the end of LIBRARY_PATH, and that
folder doesn't contain any libraries.
Afaict, it's also not true that GCC will already have this location built
in ... I'm starting to think there's some code there that hasn't been doing
anything useful at all, and that it's still there only because it hasn't
actually caused anything to break.
I'll do some testing before the next release myself, but feel
free to try it and see if you find any problems with this.
Shall do, when time permits. (Bit rushed tonight - but I wanted to get a
reply back :-)
Thanks again, Jan.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
2 MinGW-related feature requests.
Hi,
Should I submit the 2 proposals below to bugzilla ?
1) I've found that we can't actually build perl using the MinGW that gets
installed using ppm.
This happens because windres.exe cannot be found.
Adding the perl/site/lib/auto/MinGW folder fixes the problem, but perhaps it
would be better
to put an executable named windres.exe in perl/site/bin - as has been done
for ar, g77, g++,
gcc and dlltool. Btw, what does the source code for those executables look
like ?
2) ExtUtils::Liblist::Kid.pm contains the following:
if ($VC and exists $ENV{LIB} and $ENV{LIB}) {
push @libpath, split /;/, $ENV{LIB};
}
It would be really neat if the same could be done for MinGW, by adding the
following code
immediately after the above code:
# For the benefit of MinGW:
if ($GC and exists $ENV{LIBRARY_PATH} and $ENV{LIBRARY_PATH}) {
push @libpath, split /;/, $ENV{LIBRARY_PATH};
}
I've been using this in my own builds of perl for quite some time, and it's
a very handy
amendment to have in place. (Amending Kid.pm by hand every time I update
EU::MM/perl does,
however, become rather tiresome.) I asked Schwern to put it in the official
release of EU::MM,
but he refused - worried it might break something. It then occurred to me
that, since ActivePerl
ships with ActiveState's own version of EU::MM, ActiveState might be willing
to include that
code. (Better still if someone can convince Schwern to stick it in the
official release.)
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Archive::Zip problem
- Original Message -
From: Kprasad kpra...@aptaracorp.com
#!/usr/bin/perl
use Archive::Zip qw( :ERROR_CODES :CONSTANTS ); # imports
#mkdir c:/onfly;
my $localdir=c:/onfly; ## I've two zip files i.e., first.zip and
second.zip which respectively contains 3 files and two files and after
extraction 'c:/onfly/first' should contain 3 files and c:/onfly/second'
should contain 2 files only
$obj = Archive::Zip-new(); # new instance
opendir(DIR, $localdir) || print \nerror\n;
my @zipfiles=grep /$ARGV[0].*\.zip/, readdir(DIR);
close(DIR);
foreach $zipfiles (@zipfiles)
{
if($obj-read($localdir/$zipfiles) == AZ_OK) # read file contents
{
print $zipfiles\n;
$unzip=substr($zipfiles,0,length($zipfiles)-4);
print $unzip\n;
if($obj-extractTree(undef, $localdir/$unzip/)){print Extracting
$zipfiles;}}
else{die('Error in file!');}
}
#
#
Maybe you just need to create a different Archive::Zip object for each zip
file. Something like (untested):
use warnings;
use strict;
use Archive::Zip qw( :ERROR_CODES :CONSTANTS ); # imports
#mkdir c:/onfly;
my $localdir=c:/onfly;
opendir(DIR, $localdir) || print \nerror\n;
my @zipfiles=grep /$ARGV[0].*\.zip/, readdir(DIR);
close(DIR);
foreach $zipfiles (@zipfiles)
{
my $obj = Archive::Zip-new(); # new instance
if($obj-read($localdir/$zipfiles) == AZ_OK) # read file contents
{
print $zipfiles\n;
$unzip=substr($zipfiles,0,length($zipfiles)-4);
print $unzip\n;
if($obj-extractTree(undef, $localdir/$unzip/)){print Extracting
$zipfiles;}}
else{die('Error in file!');}
}
__END__
I saw this near the end of the Archive::Zip documentation:
## quote ##
When not to use Archive::Zip
If you are just going to be extracting zips (and/or other archives) you
are recommended to look at using Archive::Extract instead, as it is much
easier to use and factors out archive-specific functionality.
## end quote ##
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] Having multiple x64 compilers on Windows Vista 64
- Original Message - From: Jan Dubois j...@activestate.com I'll continue looking - and maybe even try installing again. In the meantime, any help appreciated. I think you have to run the web installer again, and then make sure you *do* select the AMD64/x64 tools. Turns out they were already there, but running another batch file (that simply adds perl to the path) before running SetEnv.cmd was hiding them ... by some mechanism that I don't understand. So I've just written a batch that runs SetEnv.cmd and then adds perl to the path, and all's working fine. Thanks (to *all* who replied) for the assistance. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] Having multiple x64 compilers on Windows Vista 64
- Original Message - From: Steve Hay steve...@planit.com But I *would* like to be able to switch between the two. Will that be possible if I go ahead and install the 2008 version ? I don't know about Vista 64, but I've got the Server 2003 SDK and the Server 2008 SDK both installed on my 32-bit XP box, and they live together quite happily. That sounds heartening - I'll wait til tomorrow, and if I haven't received any Danger, Will Robinson messages, I'll go ahead with it. I actually started to install the Server 2008 SDK but two things made me nervous (so I aborted): 1) The installation started without having asked me where I wanted things installed. I have a vague recollection that it was the same with the 2003 version (and that one gets to nominate the location later on during the installation process) - but it bothered me that I might be about to clobber critical pieces (if not the whole lot) of my 2003 installation. 2) I wasn't even sure that it was the x64 version I was about to install. (How do you tell ?) Earlier on in the day I had installed VC++ 2008, believing it to be an x64 version as many of the components were specifically labelled x64 - only to discover it was a 32-bit compiler after all. At least, I'm damned if I can get it to work with 64-bit perls, though it works fine with 32-bit perls. I also have VC6, VC7, VC8 and VC9, all running without interfering with each other as long as their environments are setup via their batch scripts, not in the system environment. Yes - I have 32-bit VC7.0 (and now, VC 2008, as mentioned above) as well as MinGW - all environments are set up by batch scripts. (The only slight niggle I have is that the default vsvars32.bat with VC9 now looks in the registry for the latest Windows SDK installed. It ships with v6.0A, so it uses that initially, but when you install the Server 2008 SDK (which is v6.1) it starts using that instead. I tweaked VC9's batch script to always use the v6.0A that it came with, and I have a separate batch script for setting up the v6.1 environment when I want to use that.) I'll keep an eye out for that sort of thing. Thanks, Steve. Appreciated. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] Having multiple x64 compilers on Windows Vista 64
- Original Message - From: Jan Dubois j...@activestate.com It's important that I don't lose the 2003 version, as it seems to be no longer readily available from MS. (All links to it quickly turn into links to the 2008 version when it comes to strating a download.) Really? I didn't have any problems finding and downloading it so far: http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADBdisplaylang=en On that page, just below the Overview heading I see the following note: NOTE: This version of the Platform SDK has been superceded by the Windows SDK for Windows Server 2008 and .NET Framework 3.5. And the Web Install link leads to http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDCdisplaylang=en which offers a Windows SDK for Windows Server 2008 and .NET Framework 3.5 download. The DVD ISO image link also leads to Windows SDK for Windows Server 2008 and .NET Framework 3.5. Or ... have I misinterpreted what I'm seeing there ? (Perhaps the continue link still leads to the installation of the SDK 2003 ?) Yes, they install into different directories. The 2003 version is even still called the Platform SDK while the 2008 version is now called the Windows SDK. You can install multiple SDKs on the same machine; just make sure you don't let it set up environment variables automatically but use the setenv.cmd for each version as you need it. Excellent news - I'll get started on it soon. On an on-topic note does the unavailability of the 2003 version mean that, at some stage, it will be no longer used to build the x64 versions of ActivePerl ? [snip] The advantage of the 2003 SDK compiler for x64 (and VC6 for x86) is that they don't require additional runtime libraries; they link against MSVCRT.dll which is already part of Windows. So any application generated with PAR / PerlApp / Perl2Exe doesn't need to bundle MSVCR80.dll. Yes, this is a good reason for using that particular compiler to build perl. As long as that compiler remains readily available, I see no cause for concern. Thanks, Jan. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] Having multiple x64 compilers on Windows Vista 64
- Original Message - From: Jan Dubois j...@activestate.com Or ... have I misinterpreted what I'm seeing there ? (Perhaps the continue link still leads to the installation of the SDK 2003 ?) Indeed, the Continue button is exactly what you have to press. It does its usual Windows Genuine Advantage verification and then lets you install the SDK, That's good to know - thanks, Jan. Sorry for the confusion. I've installed the SDK 2008. I have an AMD64 processor and Windows Vista64 SP1, so I ran: C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\setenv /Release /ia64 /2008 That tells me: The IA64 compilers are not currently installed. Please go to Add/Remove Programs to update your installation. If I specify /x64 as the second switch I get the same message, except s/IA64/x64/. And if I specify either /x86 or /vista, then it's the x86 compilers that are reported as missing. Runing 'cl /?' reports that 'cl' is not recognized as an internal or external command, operable program or batch file. Where are these compilers supposed to be ? (I would've thought in separate folders under C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin, but there are no folders in that directory.) I can find Add/Remove Programs in the control panel on XP, but not on Vista (using Classic View of the control panel). And is going to Add/Remove Programs really going to help ? I'll continue looking - and maybe even try installing again. In the meantime, any help appreciated. (Not a lot of urgency with this, btw - so please don't drop what you're doing just to find the time to offer advice. If it takes a month to get this sorted out then I reckon I've got off lightly :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ActivePerl -x64, and another problem with mixing compilers.
- Original Message - From: Jan Dubois j...@activestate.com You can actually install different versions of MSVCR80.dll on the same machine; they go into different directories under C:\Windows\WinSxS (the side-by-side installation directory). That's one helluva directory on my machine: 13 GB 14,121 folders 51,537 files Is that normal ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ActivePerl -x64, and another problem with mixing compilers.
- Original Message - From: Jan Dubois j...@activestate.com That's one helluva directory on my machine: 13 GB 14,121 folders 51,537 files Is that normal ? It is normal if you are running Vista or 2008 Server Yep - I've got Windows Vista. Makes you wonder how we ever got by when hard drives were 20 GB or less. Thanks for the elaboration (snipped), too. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
[OT] Having multiple x64 compilers on Windows Vista 64
Hi, I currently have the Microsoft Platform SDK for Windows Server 2003 R2 compiler. I would like to also install Windows SDK for Windows Server 2008 and .NET Framework 3.5 from http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDCdisplaylang=en . Will installation of the latter clobber the former in any way ? It's important that I don't lose the 2003 version, as it seems to be no longer readily available from MS. (All links to it quickly turn into links to the 2008 version when it comes to strating a download.) But I *would* like to be able to switch between the two. Will that be possible if I go ahead and install the 2008 version ? On an on-topic note does the unavailability of the 2003 version mean that, at some stage, it will be no longer used to build the x64 versions of ActivePerl ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActivePerl -x64, and another problem with mixing compilers.
Hi, A friend of mine has the same x64 build of ActivePerl as I do (namely, build 1004). He built Tk-804.028 for his perl using the 2008 compiler. I built Tk-804.028 for my perl using the Platform SDK for Windows Server 2003 R2 compiler. Both of our builds of Tk work fine on the machines on which they were built. But his (2008-built) binaries are unworkable on my machine. Once I install them, any attempt by me to 'use Tk;' produces: C:\perl -MTk -le print $Tk::VERSION Can't load 'C:/_64/perl1004/site/lib/auto/Tk/Event/Event.dll' for module Tk::Event: load_file:The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail at C:/_64/perl1004/lib/XSLoader.pm line 64. at C:/_64/perl1004/site/lib/Tk/Event.pm line 11 Compilation failed in require at C:/_64/perl1004/site/lib/Tk.pm line 13. BEGIN failed--compilation aborted at C:/_64/perl1004/site/lib/Tk.pm line 13. Compilation failed in require. BEGIN failed--compilation aborted. I thought that running vcredist_x64.exe on my machine might fix that problem, but it makes no difference - I even rebooted the machine and re-installed my friend's Tk binaries after running vcredist_x64.exe. Anyone have any ideas on what's needed to fix this incompatibility ? (Btw, we haven't tried running my SDK-built binaries on his machine - but that's not the issue.) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ActivePerl -x64, and another problem with mixing compilers.
- Original Message - From: Rob May r...@themayfamily.me.uk Anyone have any ideas on what's needed to fix this incompatibility ? It almost certainly because your friends's Event.dll will have an embedded manifest requiring the VC80 CRT which you won't have installed (although you didn't say which vcredist_x64.exe you ran on your machine). Doh !! You mean you can't run just *any* vcredist_x64.exe and expect it to work ;-) Running the *appropriate* vcredist_x64.exe fixes the problem. (The appropriate one being the one for VC++ 2008, not the one for VC++ 2005.) Have a look at this article: http://blogs.msdn.com/junfeng/archive/2006/04/14/576314.aspx for further debugging information - skip down to the Vista section, and you'll see that you can look in the event log for errors in the application log from the 'SideBySide' source to get more information about what dependency can't be located. Thanks for that additional info, too. (The Event Viewer did confirm that the required CRT could not be found.) Thanks for setting me straight, Rob. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net::SSLeay on Windows X64
- Original Message -
From: Sisyphus sisyph...@optusnet.com.au
One test failed (t/local/00_ptr_cast.t), but it fails only because it
fails
to compile a test program:
It's a bug in the test script. With some help from
http://www.perlmonks.org/index.pl?node_id=762762 , I finally found that the
executable fails to build because bufferoverflowU.lib is not linked in. In
00_ptr_cast.t, we need to change:
push(@extraargs, '/nologo') if $^O eq 'MSWin32' $Config{cc} eq 'cl';
to:
push(@extraargs, '/nologo ' . $Config{libs}) if $^O eq 'MSWin32'
$Config{cc} eq 'cl';
Then the test executable builds, and 4 of the 5 tests pass. The one test
that fails expects the empty string to be returned, but undef is being
returned. (This could well be another bug in the test script, faik.)
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net::SSLeay on Windows X64
- Original Message -
From: Jan Dubois j...@activestate.com
It's a bug in the test script. With some help from
http://www.perlmonks.org/index.pl?node_id=762762 , I finally found that
the
executable fails to build because bufferoverflowU.lib is not linked in.
This is only a problem when you are using the VC compiler from the Windows
2003 R2 Platform SDK. It is a variant of VS2005, but links against
MSVCRT.dll
instead of MSVCR80.dll. MSVCRT.dll does not contain the code necessary
for
the /GS buffer overrun protection new to VS2005, so it has to be linked
into
the generated executables statically.
I guess you probably already knew this, but wanted to state it explicitly
for the list archives.
Yep (well ... I knew *some* of it :-)
Thanks for attending to my omission.
I've just submitted a bug report to
https://rt.cpan.org/Ticket/Display.html?id=45882 containing this patch,
which I think addresses the problem in a portable way (by specifying a link
to bufferoverflowU.lib iff bufferoverflowU.lib is listed in $Config{libs}):
--- 00_ptr_cast.t_orig Sat May 9 09:51:39 2009
+++ 00_ptr_cast.t Sat May 9 10:31:59 2009
@@ -17,8 +17,12 @@
my $err = gensym();
my @extraargs;
-push(@extraargs, '/nologo') if $^O eq 'MSWin32' $Config{cc} eq 'cl';
-my $cmd = $Config{cc} -o $output $input . join(' ', @extraargs);
+my $cmd;
+if($^O eq 'MSWin32' $Config{cc} eq 'cl') {
+ push(@extraargs, '/nologo ' . $Config{libs});
+ $cmd = $Config{cc} /Fe$output $input . join(' ', @extraargs);
+}
+else {$cmd = $Config{cc} -o $output $input . join(' ', @extraargs)}
diag( compiling test program with: $cmd );
my $pid = open3(undef, $out, $err, $cmd);
waitpid $pid, 0;
It also takes care of the failure with test 2 (that I mentioned in my
previous post). With that patch in place, all of the Net-SSLeay-1.35 tests
now pass for me.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: VC 8 and 64-bit ActivePerl
- Original Message - From: Jan Dubois j...@activestate.com Do you know the actual command I need to run ? It would be something like this: mt -nologo -manifest Common.dll.manifest -outputresource:Common.dll;2 The *.manifest file gets written by link.exe when it builds the DLL using VC 8. It should be in the same directory as the *.dll. You need to call mt.exe after link.exe. I can see that the Makefile actually runs that command after link.exe: if exist blib\arch\auto\XML\LibXML\Common\Common.dll.manifest mt -nologo -manifest blib\arch\auto\XML\LibXML\Common\Common.dll.manifest -outputresource: blib\arch\auto\XML\LibXML\Common\Common.dll;2 But 'blib\arch\auto\XML\LibXML\Common\Common.dll.manifest' does not exist. Note that I'm not actually building XML-LibXML-Common with VC 8. I'm using the Platform SDK, Windows Server 2003 R2 compiler. It's just that I'm linking against dynamic xml2 and iconv libraries that were built with VC 8. It all works fine, except for the runtime error. (There must surely be a way of resolving this without having to build the libraries using the SDK compiler.) I did find a manifest file for an x86 Net::SSH2 dll, and I've tried to create a manifest file for Common.dll based on it. But I don't seem to be able to get it right. With my Common.dll.manifest file in place, I can then successfully run the mt.exe command, but 'nmake test' then outputs the error: Can't load 'blib\arch/auto/XML/LibXML/Common/Common.dll' for module XML::LibXML: :Common: load_file:The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail at C:/_64/perl1004/lib/DynaLoader.pm line 202. at test.pl line 10 Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: VC 8 and 64-bit ActivePerl
- Original Message - From: Jan Dubois j...@activestate.com To: 'Sisyphus' sisyph...@optusnet.com.au; perl-win32-users@listserv.ActiveState.com Sent: Friday, May 08, 2009 2:39 AM Subject: RE: VC 8 and 64-bit ActivePerl On Thu, 07 May 2009, Sisyphus wrote: From: Jan Dubois j...@activestate.com Are you sure you are dynamically linking against xml2 and iconv libraries? Yes - if either msvcr80.dll, libxml2.dll, or libiconv.dll cannot be found, I get a pop-up telling me so. In that case there would be no need for your DLL to contain the manifest; only the xml2 and iconv2 libraries themselves would have to embed it. Bingo - that's it !! Hidden away in the lib folder of this pre-compiled package I found a libxml2.dll.manifest, which I then embedded into the libxml2.dll using mt.exe - and 'nmake test' now succeeds, passing all tests. There was no manifest for the iconv dll, but apparently it doesn't need it. (Perhaps the manifest is already embedded in it.) Thanks again, Jan. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net::SSLeay on Windows X64
- Original Message - From: OBrennan, Gerry obren...@mst.edu To: perl-win32-users@listserv.ActiveState.com Sent: Thursday, May 07, 2009 11:49 PM Subject: Net::SSLeay on Windows X64 We're running Activestate Perl 5.10.0.1004 on Windows x64. We are interested in the Net::SSLeay package for x64, but we have not had success locating a PPM that works, nor success build it using the free compilers/linkers available. Do you have the compiler that built ActivePerl 5.10.0.1004 for Windows x64 ? It's called Windows Server 2003 R2 Platform SDK and you can get it at at: http://www.microsoft.com/downloads/details.aspx?familyid=484269E2-3B89-47E3-8EB7-1F2BE6D7123Adisplaylang=en You can get an x64 build of openssl (that was built using VC 8) from http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC8/x64/ I grabbed http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC8/x64/openssl-0.9.8h-vc8-x64.zip and have just used my Windows Server 2003 R2 Platform SDK compiler to build Net-SSLeay-1.35 against that VC 8 build of openssl. (I have the same build of perl as you, btw.) One test failed (t/local/00_ptr_cast.t), but it fails only because it fails to compile a test program: fatal error C1083: Cannot open compiler generated file: 'ptr_cast_test.obj': Permission denied Not sure why that error occurs - I'll have to play around with it. All other tests pass. If you don't want to mess around trying to build Net-SSLeay-1.35 yourself, I could send you a ppm package of it - just let me know. I've never used ppm with my x64 build of perl ... I assume it works fine with the x64 builds. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
VC 8 and 64-bit ActivePerl
Hi, Playing around trying to build XML-LibXML-Common-0.13 on 64-bit ActivePerl (build 1004, perl-5.10.0). I'm using the Platform SDK for Windows 2003 R2 compiler (which is the compiler that was used to build perl), but the x64 libxml2 and libiconv libraries I'm building against were built using the VC 8 compiler. It all builds fine, but as soon as the tests are run , there's this nasty runtime error crops up when the attempt is made to load XML::LibXML::Common: ## C:\_32\comp\XML-LibXML-Common-0.13nmake test Microsoft (R) Program Maintenance Utility Version 7.00.8882 Copyright (C) Microsoft Corp 1988-2000. All rights reserved. C:\_64\perl1004\bin\perl.exe -Iblib\lib -Iblib\arch test.pl 1..8 # Running under perl version 5.01 for MSWin32 # Win32::BuildNumber 1004 # Current time local: Thu May 7 10:37:41 2009 # Current time GMT: Thu May 7 00:37:41 2009 # Using Test.pm version 1.25 Can't load 'blib\arch/auto/XML/LibXML/Common/Common.dll' for module XML::LibXML: :Common: load_file:%1 is not a valid Win32 application at C:/_64/perl1004/lib/DynaLoader.pm line 202. at test.pl line 10 Compilation failed in require at test.pl line 10. BEGIN failed--compilation aborted at test.pl line 10. NMAKE : fatal error U1077: 'C:\_64\perl1004\bin\perl.exe' : return code '0x2' Stop. ## I'm wondering: a) What's causing this ? Is it because of the VC 8 compiler involvement ? b) What to do about it ? Do I need to build libxml2 and libiconv for myself using the Platform SDK compiler ? I'm running Windows Vista64 on an AMD64 box. Advice welcome. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: VC 8 and 64-bit ActivePerl
- Original Message - From: Sisyphus sisyph...@optusnet.com.au ## C:\_32\comp\XML-LibXML-Common-0.13nmake test Microsoft (R) Program Maintenance Utility Version 7.00.8882 Copyright (C) Microsoft Corp 1988-2000. All rights reserved. C:\_64\perl1004\bin\perl.exe -Iblib\lib -Iblib\arch test.pl 1..8 # Running under perl version 5.01 for MSWin32 # Win32::BuildNumber 1004 # Current time local: Thu May 7 10:37:41 2009 # Current time GMT: Thu May 7 00:37:41 2009 # Using Test.pm version 1.25 Can't load 'blib\arch/auto/XML/LibXML/Common/Common.dll' for module XML::LibXML: :Common: load_file:%1 is not a valid Win32 application at C:/_64/perl1004/lib/DynaLoader.pm line 202. at test.pl line 10 Compilation failed in require at test.pl line 10. BEGIN failed--compilation aborted at test.pl line 10. NMAKE : fatal error U1077: 'C:\_64\perl1004\bin\perl.exe' : return code '0x2' Stop. ## When I use a 64-bit version of msvcr80.dll (instead of the 32-bit version I was inadvertently using), the error changes: C:\_32\comp\XML-LibXML-Common-0.13nmake test Microsoft (R) Program Maintenance Utility Version 7.00.8882 Copyright (C) Microsoft Corp 1988-2000. All rights reserved. C:\_64\perl1004\bin\perl.exe -Iblib\lib -Iblib\arch test.pl 1..8 # Running under perl version 5.01 for MSWin32 # Win32::BuildNumber 1004 # Current time local: Thu May 7 11:24:56 2009 # Current time GMT: Thu May 7 01:24:56 2009 # Using Test.pm version 1.25 Can't load 'blib\arch/auto/XML/LibXML/Common/Common.dll' for module XML::LibXML: :Common: load_file:A dynamic link library (DLL) initialization routine failed at C:/_64/perl1004/lib/DynaLoader.pm line 202. at test.pl line 10 Compilation failed in require at test.pl line 10. BEGIN failed--compilation aborted at test.pl line 10. NMAKE : fatal error U1077: 'C:\_64\perl1004\bin\perl.exe' : return code '0x22' Stop. That's accompanied by a pop-up informing me that a runtime error (R6034) has occurred. In part, the pop-up says An application has made an attempt to load the C runtime library incorrectly. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: VC 8 and 64-bit ActivePerl
- Original Message - From: Jan Dubois j...@activestate.com Either that, or you could embed the manifest manually into your Common.dll using the mt.exe tool. Thanks Jan. I've taken a look at 'mt /?' and can't see anything there that makes any sense at all to me. Do you know the actual command I need to run ? There's no 'manifest' file anywhere in the build directory (apart from the MANIFEST that ships with the XML-LibXML-Common source). I've tried updating to EU::MM-6.50, but that makes no difference. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: perl to dll?
- Original Message - From: Daniel Burgaud burg...@gmail.com To: Perl-Win32-Users perl-win32-users@listserv.ActiveState.com Sent: Sunday, April 19, 2009 11:49 PM Subject: perl to dll? Hi All, I know there is a perl to exe, but what about a perl to dll? Not sure ... doesn't ActiveState's PDK (Perl Development Kit) have something like that ? I don't think the PDK is free, however. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Reset in ANSIColor sets the background to black
- Original Message -
From: Perl Help perlhel...@gmail.com
To: Sisyphus sisyph...@optusnet.com.au
Cc: perl-win32-users@listserv.activestate.com
Sent: Wednesday, April 01, 2009 9:32 AM
Subject: Re: Reset in ANSIColor sets the background to black
Hi Rob,
I am facing another problem with this code. When I call the function twice
in the same script, it throws me the following error:
Error Msg: Test[This is in Red color as expected for the first function
call]
Use of uninitialized value in bitwise and () at test.pl line 12.
My Script is :
#33 START #3
use strict;
use warnings;
use Win32::Console;
ErrorMsg('Test');
ErrorMsg('Test');
sub ErrorMsg {
my $error = shift;
my $console = Win32::Console-new(STD_OUTPUT_HANDLE);
my $CurrentConsoleColor = $console-Attr;
my $BackgroundColor = $CurrentConsoleColor
(BACKGROUND_RED|BACKGROUND_BLUE|BACKGROUND_GREEN|BACKGROUND_INTENSITY);
# This sets the text color on DOS in red with intensity
$console-Attr(FOREGROUND_RED|FOREGROUND_INTENSITY|$BackgroundColor);
print \nError Msg: $error \n;
$console-Attr($CurrentConsoleColor);
}
Hi Jai,
One solution is to create and assign to $console outside of the subroutine
(and before the subroutine is called). This works fine for me:
#
use strict;
use warnings;
use Win32::Console;
my $console = Win32::Console-new(STD_OUTPUT_HANDLE);
ErrorMsg('Test');
ErrorMsg('Test again');
ErrorMsg(' ... and again');
sub ErrorMsg {
my $error = shift;
my $CurrentConsoleColor = $console-Attr;
my $BackgroundColor = $CurrentConsoleColor
(BACKGROUND_RED|BACKGROUND_BLUE|BACKGROUND_GREEN|BACKGROUND_INTENSITY);
# This sets the text color on DOS in red with intensity
$console-Attr(FOREGROUND_RED|FOREGROUND_INTENSITY|$BackgroundColor);
print \nError Msg: $error \n;
$console-Attr($CurrentConsoleColor);
}
#
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Vista?
- Original Message - From: Jon Bjornstad j...@logicalpoetry.com To: perl-win32-users@listserv.ActiveState.com Sent: Monday, March 30, 2009 4:29 PM Subject: Vista? How can I tell if I'm running on Vista instead of XP? $^O tells me I'm on Windows but not which version. perl -MWin32 -e print Win32::GetOSName() or you can also make use of the Win32::GetOSVersion() function. See 'perldoc Win32' for details. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Window control - which module to use?
- Original Message -
From: Jon Bjornstad j...@logicalpoetry.com
1 - How to ensure that there are not two versions of my script running?
One way is to have your script do something that prevents multiple instances
of it from being run.
Something like:
##
use warnings;
my $remove = 1;
if(-f 'script.lockfile') {
$remove = 0; # prevents removal of lockfile
die lockfile exists\n;
}
open(WR, '', 'script.lockfile') or die $!;
close WR or die $!;
# Do the stuff you want to do here
END {
if($remove) {
warn lockfile not removed if !unlink 'script.lockfile';
}
};
##
Of course, if you're worried that someone might manually remove the lockfile
so that they can run multiple instances of the script, then that solution
won't do. (Or maybe someone might manually create a 'script.lockfile' file
so that *no* instances of the script can be run.)
And if there's a system crash while the script is running then the lockfile
may not get removed automatically.
Another thing you can do is have the script connect to a socket. That way, a
second instance of the script will try to connect to the same socket ... and
fail as the socket is already in use. (Of course, if there's another
entirely different process using the same port then you won't be able to run
even one instance of the script.)
There are probably more sophisticated solutions, if needed.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Reset in ANSIColor sets the background to black
- Original Message -
From: Perl Help perlhel...@gmail.com
To: perl-win32-users@listserv.ActiveState.com
Sent: Friday, March 27, 2009 7:00 AM
Subject: Reset in ANSIColor sets the background to black
Hi,
My current DOS background color is white with Black text. I use ANSIColor
module to print error messages in Red color. I use the Color command and I
face two issues:
1. The Red color error message text thats printed on DOS has black
background, instead of white only.
2. On typing CLS the background color changes to black and text color
changes to white.
What is my Expectation:
1. On prinitng the text in red color should not have the background color
black but use the current DOS background color(White in my case).
2. On doing CLS on DOS, the dos should maintain its background color(White
in my case) rather then setting it to default black background color.
My Code:
use Win32::Console::ANSI;
use Term::ANSIColor;
print color Bold Red;
print ERROR_MSG = xyz;
print color 'reset';
Any help is much appreciated.
You might also look at Win32::Console and Win32::ANSIScreen. Between those
modules and the ones you've already loaded you might be able to get the job
done.
For example, with Win32::Console, you can get the current color attributes:
use warnings;
use Win32::Console;
$c = new Win32::Console STD_OUTPUT_HANDLE;
$c-Alloc();
$attr = $c-Attr();
print $attr, \n;
Faik, you can also get the current attributes using Win32::Console::ANSI -
but I couldn't quickly see from the documentation how that could be done.
But Win32::Console::ANSI seems to clobber the handle (I had difficulty
finding a way to reset the colors back to the original), and I got sick of
trying to find a way to get it all to work nicely. In the end, I re-invented
the wheel using Inline::C and it works fine:
#
use warnings;
use strict;
use Inline C = Config =
BUILD_NOISY = 1;
use Inline C = 'EOC';
SV * get_handle() {
return newSVuv((HANDLE)GetStdHandle(STD_OUTPUT_HANDLE));
}
SV * get_attr(SV * h) {
CONSOLE_SCREEN_BUFFER_INFO Info;
if(!GetConsoleScreenBufferInfo((HANDLE)SvUV(h), Info))
croak(Error obtaining current attributes);
return newSVuv(Info.wAttributes);
}
void set_attr(SV * h, SV * attr) {
if(!SetConsoleTextAttribute((HANDLE)SvUV(h), (WORD)SvUV(attr)))
croak(Error setting attributes);
}
EOC
use constant {
FOREGROUND_BLUE = 1,
FOREGROUND_GREEN = 2,
FOREGROUND_RED = 4,
FOREGROUND_INTENSITY = 8,
BACKGROUND_BLUE = 16,
BACKGROUND_GREEN = 32,
BACKGROUND_RED = 64,
BACKGROUND_INTENSITY = 128};
$| = 1;
my $h = get_handle();
my $current = get_attr($h);
my $current_background = $current (BACKGROUND_RED | BACKGROUND_BLUE
| BACKGROUND_GREEN | BACKGROUND_INTENSITY);
# $current_foreground not needed in this script
my $current_foreground = $current (FOREGROUND_RED | FOREGROUND_BLUE
| FOREGROUND_GREEN | FOREGROUND_INTENSITY);
# Set $message to intense red on current background
my $message = FOREGROUND_RED | FOREGROUND_INTENSITY |
$current_background;
set_attr($h, $message);
print ERROR_MSG = xyz;
# Restore original foreground/background colours.
set_attr($h, $current);
print \n All Done\n;
#
Of course, you'll need a compiler and make utility. Running 'ppm install
MinGW' will take care of that for you - it will provide you with the MinGW
port of gcc and dmake. Then install Inline::C using that compiler and make
utility, and away you go. (Don't 'ppm install Inline-C'.)
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Reset in ANSIColor sets the background to black - alternative
- Original Message - From: Perl Help perlhel...@gmail.com Any help is much appreciated. A less solution that doesn't re-invent any wheels: ## use Win32::Console; use warnings; use strict; $| = 1; my $c = new Win32::Console STD_OUTPUT_HANDLE; $c-Alloc(); my $current = $c-Attr(); my $current_fg = $current (FOREGROUND_RED | FOREGROUND_BLUE | FOREGROUND_GREEN | FOREGROUND_INTENSITY); my $current_bg = $current (BACKGROUND_RED | BACKGROUND_BLUE | BACKGROUND_GREEN | BACKGROUND_INTENSITY); $c-Attr(FOREGROUND_RED | FOREGROUND_INTENSITY | $current_bg); print ERROR_MSG = xyz; $c-Attr($current); ## But I don't see how to achieve it with Win32::Console::ANSI - mainly because I don't see how to print color 'bold red on current background'; or print colored (ERROR_MSG = xyz, 'bold red on current background'); Do you need to use Win32::Console::ANSI ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: XML::LibXML
- Original Message - From: Neson Maxmelbin (RBEI/EMT4) maxmelbin.ne...@in.bosch.com To: perl-win32-users@listserv.ActiveState.com Sent: Friday, March 13, 2009 6:58 PM Subject: XML::LibXML Hello All, I am trying to find the ppd file for XML::LibXML module .. Can anyone provide me a link .. My perl ver is v5.6.1 build 638 == ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/XML-LibXML.ppd Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: IO::Socket (client program sends simple text file containing CRLFnewlines)
- Original Message - From: Greg Aiken gai...@visioninfosoft.com I use IO::Socket as basis for a client program. I think you mean that it's a *server* program . my program opens the above referenced file (for read), then reads each line of the file, then sends each record read out through the socket. I have an IO::Socket server that does the same over a local network - it is definitely sending each 0x0d 0x0a pair as is. For example, I have the following file: 68 65 6C 6C 6F 20 77 6F 72 6C 64 0D 0A When I send that to either a Win32 box or a Linux box, the file that is reproduced there is identical. (On the Linux box, in re-creating the file, I have to binmode the filehandle I'm writing to. Otherwise Linux removes the 0x0d. But if I'm sending to the Win32 box, then it makes no difference whether that filehandle is binmoded or not. All of this is as expected.) In short, I'm unable to reproduce the behaviour you describe. however, I use 'wireshark' to monitor the client/server communication here and it is able to capture all tcp data being sent through my used port number. wireshark then can save to disk the captured data packet. I discovered that something here seems to be amiss regarding the CRLF byte pair. 'wireshark' captured transmitted data reveals that only the LF byte was being sent! somehow the CR byte does NOT get transmitted. Is everything described above happening on Windows boxes ? For example, if wireshark were running on a linux box, I would not be at all surprised if wireshark converted '0x0d 0x0a' to '0x0a' when saving the captured data to disk. (I know nothing about wireshark, btw.) I don't think IO::Socket is responsible for removing the CR's. If they're being removed, then it's happening either before or after the data has been sent. But it's hard to work out how that would be happening from the info provided. Are you running any of this in Cygwin ? (I'm just thinking that a Cygwin perl filehandle that has been opened for reading might remove the '0x0d' unless it has been binmode()d ... but I don't know.) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: PPM issue
- Original Message -
From: Conor Lillis [EMAIL PROTECTED]
To: perl-win32-users@listserv.ActiveState.com
Sent: Friday, December 05, 2008 2:07 AM
Subject: PPM issue
Hi guys
I have an issue below on running PPM on any packages, has anyone
encountered this issue before or do they have a workaround?
D:\Admin\Scriptsppm install net-dns
Install 'Net-IP' version 1.25 in ActivePerl 5.8.7.815.
Couldn't read chunk at offset unknown at
C:/perl/site/lib/PPM/Archive/Tar.pm line 25
Error: Can't call method is_label on an undefined value at
C:/perl/site/lib/Archive/Tar.pm line 282.
Doesn't ring any bells with me.
What version of Archive::Tar do you have ?
What's on line 25 ? and line 282 ?
For me (version 1.38_01):
-
21: $CHMOD = 1;
22: $DO_NOT_USE_PREFIX = 0;
23: $INSECURE_EXTRACT_MODE = 0 unless defined $INSECURE_EXTRACT_MODE;
24:
25: BEGIN {
26: use Config;
27: $HAS_PERLIO = $Config::Config{useperlio};
28:
29: ### try and load IO::String anyway, so you can dynamically
30: ### switch between perlio and IO::String
-
-
278: ### line 111
279: { my $nulls = join '', \0 x 12;
280: unless( $nulls eq substr( $chunk, 500, 12 ) ) {
281: $self-_error( qq[Invalid header block at offset
$offset] );
282: next LOOP;
283: }
284: }
285:
286: ### pass the realname, so we can set it 'proper' right away
287: ### some of the heuristics are done on the name, so important
-
But I have the latest (build 824, perl-5.8.8).
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: NET::SSH2 - No Output
- Original Message - From: SelfSimilar [EMAIL PROTECTED] To: perl-win32-users@listserv.ActiveState.com Sent: Friday, December 05, 2008 6:34 AM Subject: NET::SSH2 - No Output After successfully establishing a SSH connection I use the following code snippet, variations of which have been posted many places. my $chan = $ssh2-channel(); $chan-shell(); $chan-blocking(0); my ($len, $buf); $chan-write(ls\n); select(undef,undef,undef,0.25); print $buf while (($len = $chan-read($buf,512)) 0); As an alternative, that could be replaced with: my $chan = $ssh2-channel(); my ($len, $buf) = (1000, ' ' x 1000); $chan-exec(ls\n); $chan-read($buf, $len); print $buf, \n; One problem with that replacement code is that you need to allocate a sufficiently large buffer ($buf). It doesn't matter if $buf is larger than necessary, but if it's smaller than needed then you miss out on the extra data. I get an error message Use of uninitialized value in numeric gt () at SFTP_test2.pl line 21 which is the print statement It's not an error message - it's a warning which you could eliminate with (at the beginning of your script): no warnings 'uninitialized'; I get the same warning with your code, but I also get the ls output printed out before the warning appears. Is it the same for you ? Are you using perl 5.8.x or 5.10.0 ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: NET::SSH2 - No Output
- Original Message - From: SelfSimilar [EMAIL PROTECTED] . . $chan-write(ls\n); If the ls command throws an error, you won't get to see what the error is. (You'll simply get no output.) Better to write: $chan-write(ls 21\n); That way, any error message will end up in the buffer, and you'll get to see it. For the same reason, the same change should be made to the alternative code that I provided earlier. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Attempting to Install Net::SSH2 on Activestate 5.8.7 build 815 (Sameproblem as this thread Net::SSH2 v0.18)
- Original Message - From: Gregory J. Donaldson [EMAIL PROTECTED] To: perl-win32-users@listserv.ActiveState.com Sent: Wednesday, December 03, 2008 10:15 AM Subject: Attempting to Install Net::SSH2 on Activestate 5.8.7 build 815 (Sameproblem as this thread Net::SSH2 v0.18) Hello, I am running into the exact same problem that was outlined in the thread titled Net::SSH2 v0.18. I am running on an old version of perl Activestate 5.8.7 build 815 and have tried to install Net::SSH2. I am now getting the Perl_sv_2iv_flag error. Unfortunately, at this point upgrading Perl is not possible. I was wondering if I could get a copy of SSH2.dll built with 5.8.0. There was a reference that it might get loaded onto the uwinnipeg repository but if it was I couldn't find it. = You should be able to install it with: ppm install http://theoryx5.uwinnipeg.ca/ppms/Net-SSH2.ppd (Please let me know if there's a problem with that there shouldn't be :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
[OT]Trying to contact Neil Watkiss
Hi, Some time back Neil offered me co-maintainership of Inline::CPP ... and I didn't take him up on the offer. I've since decided that I *would* like to take it on, but I don't have a current email address for him. Does anyone here happen to have a current email address for Neil ? I think he had an address at activestate.com recently - hence my reason for asking here. Aditionally, I've tried his CPAN address and [EMAIL PROTECTED] (where I successfully made my initial contact with him some months back). But all attempts have bounced. And I also contacted Stefan Seifert, who recently took over maintainership of one of Neil's other modules (Inline::Python), thinking that he might be able to help. But he, too, had been unable to contact Neil - the maintainership was set up for Stefan by the PAUSE admins. I'll take the same route, too, if need be, though I'd prefer to raise the matter with Neil first if I can find him :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net::SSH2 v0.18
- Original Message - From: listmail [EMAIL PROTECTED] . . Dialog title: perl.exe - Entry Point Not Found Dialog text : The procedure entry point Perl_sv_2uv_flags could not be located in the dynamic link library perl58.dll. Damn - looks like I built that ppm using 5.8.8. It should have been built using 5.8.0 - in which case you wouldn't be having this trouble. I'll send you (offlist) a SSH2.dll built with 5.8.0. If you replace your existing auto/Net/SSH2/SSH2.dll with it, then all should be fine. If you could then confirm that fixes the problem, I'll send Randy a corrected (5.8.0-built) binary for inclusion on the Uwinnipeg rep so that others don't strike the same problem. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Net::SSH2 v0.18
- Original Message - From: listmail [EMAIL PROTECTED] To: perl-win32-users@listserv.ActiveState.com Sent: Wednesday, November 05, 2008 4:43 AM Subject: Net::SSH2 v0.18 I can't get Net::SSH2 0.18 working. I had Net::SSH2 0.09 working without having to do any extra steps, but I never migrated my programs over from using the old Net::SSH::W32Perl. I installed 0.18 via the default repo, it failed the test, removed it and installed from ppm install http://theoryx5.uwinnipeg.ca/ppms/Net-SSH2.ppd which is the same version, and it failed with the same error. (Aside: I'm finding that ppm installs from uwinnipeg are very slow these days. Is that just low bandwidth being provided by the server ? ... or something else. It took me about 30 minutes to install Net-SSH2-0.18, and I've noticed slow downloads with all of the other modules I've recently installed from that repo. Anyone else noticed the same ? Downloads from the ActiveState repo still proceed quite quickly for me.) To test i simply create a perl script with a use Net::SSH2; call and then run it and I immediately get this error: Can't load 'C:\perl\site\lib/auto/Net/SSH2/SSH2.dll' for module Net::SSH2: load_file:The specified procedure could not be found at C:\perl\site\lib/XSLoader.pm line 64. at C:\perl\site\lib/Net/SSH2.pm line 466 Compilation failed in require at C:\testing\ssh2.pl line 5. BEGIN failed--compilation aborted at C:ssh2.pl line 5. Presumably you get the same behaviour with: perl -MNet::SSH2 -e print $Net::SSH2::VERSION The file C:\perl\site\lib\auto\Net\SSH2\SSH2.dll does exist (path delimeters corrected vs. what is above) but this error sounds like (speculation on my part) either that SSH2.dll doesn't contain code that it should have or some other dependency is missing, but I thought that would should have been handled by the ppm install process. I think that's all fairly accurate - though there is no other dependency for that SSH2.dll. Term::ReadKey is needed (and should have been installed if missing), but I think that has no bearing on this particular problem. ActivePerl 5.8.8 820 Windows XP SP2 I have ActivePerl 5.8.8 824. I ran: C:\_32ppm remove Net-SSH2 Net-SSH2: uninstalled C:\_32ppm install http://theoryx5.uwinnipeg.ca/ppms/Net-SSH2.ppd Downloading Net-SSH2-0.18...done Unpacking Net-SSH2-0.18...done Generating HTML for Net-SSH2-0.18...done Updating files in site area...done 13 files installed 7 files updated C:\_32perl -MNet::SSH2 -e print $Net::SSH2::VERSION 0.18 C:\_32 As you can see, it all seems to be working fine for me. I don't think your problem has anything to do with the ppm package itself. Could you run through that same procedure I used - making sure that the SSH2.pm and SSH2.dll are, in fact, being removed by the 'ppm remove Net-SSH2' command. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] patch.exe on Vista is unusable.
- Original Message - From: Jan Dubois [EMAIL PROTECTED] To: 'Sisyphus' [EMAIL PROTECTED]; 'perl-win32-users' perl-win32-users@listserv.ActiveState.com Sent: Saturday, September 27, 2008 10:44 AM Subject: RE: [OT] patch.exe on Vista is unusable. On Wed, 24 Sep 2008, Sisyphus wrote: Despite the fact that this is a great and wondrous innovation on the part of Microsoft (I bet Linux wish they'd thought of it first), I would like to remove this behaviour. Anyone know how to do that ? I think I figured it out: In the policy editor open Local Security Policy, navigate to Security Settings, Local Policies, Security Options and then deactivate the User Account Control: Detect application installations and prompt for elevation policy. Thanks for giving it more thought, Jan. (I'm starting to feel embarrased now at the effort you've gone to.) I got into Local Policies by first running secpol.msc as administrator, and then deactivated the control you mention, but nothing seems to have changed. I owe Jack an apology, too. If I run the cmd.exe console as Administrator I *can* run patch.exe fine, irrespective of whether the manifest file is present or not. (I had misunderstood Jack's advice.) I've also since discovered that I can run Cygwin's patch fine from within Cygwin's bash shell. So, at least I do have options for getting the job done. (It may be that the Cygwin bash shell is running with Administrator privileges.) Given that I don't need to run 'patch' all that often, I can probably make do with the workarounds that I've got at my disposal. After all, it's not a great imposition to open a cmd.exe shell as administrator. Still ... it's a damn strange thing to have come up against Thanks guys. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [OT] patch.exe on Vista is unusable.
- Original Message - From: Sisyphus [EMAIL PROTECTED] To: perl-win32-users perl-win32-users@listserv.ActiveState.com Sent: Thursday, September 25, 2008 1:41 PM Subject: [OT] patch.exe on Vista is unusable. . . Does anyone have a working patch.exe on Vista ? There's actually nothing wrong with the patch.exe files. The problem is that Vista won't let me run any executable whose name =~ m/patch/i without first getting my Administrator password. Vista doesn't care what the file actually does - it just decides that any executable whose name =~ m/patch/i needs admin privileges to run, and that it can't be run from the command line. (This of course means that I can rename patch.exe to, say, othername.exe, and I can then run it fine - but I have to run it as 'othername', not 'patch'.) Despite the fact that this is a great and wondrous innovation on the part of Microsoft (I bet Linux wish they'd thought of it first), I would like to remove this behaviour. Anyone know how to do that ? Cheers, Rob Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: NET SSH2 ppm for 5.10
- Original Message - From: Serguei Trouchelle [EMAIL PROTECTED] . . Try this: ppm install http://trouchelle.com/ppm10/Net-SSH2.ppd Didn't realize you had built one, Serguei. When I use your ppm, if I run the attached test script (using the SSH2 server on my linux box at 192.168.0.3 for the extended tests) , the script segfaults after test 28 has been run. Here's the output: --- C:\_32\comp\Net-SSH2-0.18_5.10perl t/Net-SSH2.t 1..72 ok 1 - use Net::SSH2; ok 2 - new session isa Net::SSH2 ok 3 - error state clear ok 4 - set banner ok 5 - LIBSSH2_* constants ok 6 - libSSH2 version 0.18 0.16 ok 7 - list version match ok 8 - decimal version matches ok 9 - banner is SSH-2.0-libssh2_0.18 ok 10 - poll indefinite ok 11 - poll 1/4 second To test the connection capabilities of Net::SSH2, we need a test site running a secure shell server daemon. Enter 'localhost' to use this host. Select host [ENTER to skip]: 192.168.0.3 ok 12 - connect to 192.168.0.3 ok 13 - kex method: diffie-hellman-group-exchange-sha1 ok 14 - hostkey method: ssh-rsa ok 15 - crypt_cs method: aes256-cbc ok 16 - crypt_sc method: aes256-cbc ok 17 - mac_cs method: hmac-sha1 ok 18 - mac_sc method: hmac-sha1 ok 19 - comp_cs method: none ok 20 - comp_sc method: none ok 21 - have MD5 hostkey hash ok 22 - have SHA1 hostkey hash Enter username: rob ok 23 - authenticate: publickey,password,keyboard-interactive ok 24 - list matches comma-separated ok 25 - not authenticated yet Enter password: ok 26 - authenticated via: password ok 27 - authenticated successfully ok 28 - new channel isa Net::SSH2::Channel At which point the process gets killed --- With the ppm that I built (and which is now available from the uwinnipeg rep), that doesn't happen: --- C:\_32\comp\Net-SSH2-0.18_5.10perl t/Net-SSH2.t 1..72 ok 1 - use Net::SSH2; ok 2 - new session isa Net::SSH2 ok 3 - error state clear ok 4 - set banner ok 5 - LIBSSH2_* constants ok 6 - libSSH2 version 0.18 0.16 ok 7 - list version match ok 8 - decimal version matches ok 9 - banner is SSH-2.0-libssh2_0.18 ok 10 - poll indefinite ok 11 - poll 1/4 second To test the connection capabilities of Net::SSH2, we need a test site running a secure shell server daemon. Enter 'localhost' to use this host. Select host [ENTER to skip]: 192.168.0.3 ok 12 - connect to 192.168.0.3 ok 13 - kex method: diffie-hellman-group-exchange-sha1 ok 14 - hostkey method: ssh-rsa ok 15 - crypt_cs method: aes256-cbc ok 16 - crypt_sc method: aes256-cbc ok 17 - mac_cs method: hmac-sha1 ok 18 - mac_sc method: hmac-sha1 ok 19 - comp_cs method: none ok 20 - comp_sc method: none ok 21 - have MD5 hostkey hash ok 22 - have SHA1 hostkey hash Enter username: rob ok 23 - authenticate: publickey,password,keyboard-interactive ok 24 - list matches comma-separated ok 25 - not authenticated yet Enter password: ok 26 - authenticated via: password ok 27 - authenticated successfully ok 28 - new channel isa Net::SSH2::Channel ok 29 - set blocking ok 30 - not at EOF ok 31 - normal extended data handling ok 32 - merge extended data ok 33 - empty setenv ok 34 - set environment variables ok 35 - verify session ok 36 - set disconnect callback ok 37 - SFTP session isa Net::SSH2::SFTP ok 38 - verify session ok 39 - create directory net_ssh2_4048 ok 40 - stat directory ok 41 - type is directory ok 42 - directory name matches ok 43 - put t/Net-SSH2.t to remote ok 44 # skip - IO::Scalar required ok 45 # skip - IO::Scalar required ok 46 - unlink non-existant file fails ok 47 - got LIBSSH2_FX_NO_SUCH_FILE error ok 48 - rename net_ssh2_4048/Net-SSH2.t - net_ssh2_4048/Net-SSH2.t.renamed ok 49 - stat net_ssh2_4048/Net-SSH2.t.renamed ok 50 - stat filename matches ok 51 - stat filesize matches ok 52 - opened file isa Net::SSH2::File ok 53 - compare stat and fstat ok 54 - compare fstat % and %$ ok 55 - opened directory isa Net::SSH2::Dir ok 56 - found net_ssh2_4048/Net-SSH2.t.renamed ok 57 - opened file isa Net::SSH2::File 'ot ok 58 - read '\# THIS LINE WILL BE READ BY A TEST BELOW '' Failed test 'read '\# THIS LINE WILL BE READ BY A TEST BELOW # at t/Net-SSH2.t line 192. ' got: '# THIS LINE WILL BE READ BY A TEST BELOW # expected: '# THIS LINE WILL BE READ BY A TEST BELOW' ok 59 - unlink net_ssh2_4048/Net-SSH2.t.renamed ok 60 - remove directory net_ssh2_4048 ok 61 - close SFTP session ok 62 - exec 'ls -d /' not ok 63 - got poll response # Failed test 'got poll response' # at t/Net-SSH2.t line 205. not ok 64 - got input event # Failed test 'got input event' # at t/Net-SSH2.t line 206. not ok 65 - got result '/' # Failed test 'got result '/'' # at t/Net-SSH2.t line 208. # got: undef # expected: '/' ok 66 - no more lines ok 67 # skip - public key infrastructure not present ok 68 # skip - public key infrastructure not present ok 69 # skip - public key infrastructure not present ok
Re: [OT] patch.exe on Vista is unusable.
- Original Message - From: Jan Dubois [EMAIL PROTECTED] To: 'Sisyphus' [EMAIL PROTECTED]; 'perl-win32-users' perl-win32-users@listserv.ActiveState.com Sent: Thursday, September 25, 2008 5:15 PM Subject: RE: [OT] patch.exe on Vista is unusable. . . Despite the fact that this is a great and wondrous innovation on the part of Microsoft (I bet Linux wish they'd thought of it first), I would like to remove this behaviour. Anyone know how to do that ? Did you try to create a patch.exe.manifest file in the same directory as patch.exe that request to run asInvoker? Just gave it a try now - but no luck. I get a pop-up telling me that The requested operation requires elevation. If this doesn't work, download the ACT (Application Compatibility Toolkit) from Microsoft and try to apply a runAsInvoker shim to the executable. There may also be a location in the registry to specify the requested execution level. I'll pursue that at some stage. For the moment I'll just rename 'patch.exe' to 'patsh.exe' - which works fine. When I first posted about this I didn't realize that a rename would work. I had tried renaming the file to 'my_patch.exe', but when the problem persisted I thought there must be more to it than a simple rename. It didn't occur to me at that time that the filename must !~ m/patch/i. I also tried out Jack's suggestion involving Run as administrator, but couldn't get anywhere with that either. Thanks Jack, Jan. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
[OT] patch.exe on Vista is unusable.
Hi, Well ... it's some perl source that I'm wanting to be able to patch. (But,yeah ... I know ... that doesn't count :-) Does anyone have a working patch.exe on Vista ? At every attempt I make to run 'patch' from the cmd.exe command line I'm prompted for admin password and, having provided that, the bloody thing then gets executed (ie runs and exits in a flash) instead of being run from the command line like I want. This happens for: 1) The patch.exe that's part of MSYS. (If I try to run that particular patch.exe from the MSYS shell I just get a flat permission denied.); 2) GNU patch-2.5.9-7; 3) The patch.exe that I just copied across from my Windows 2000 machine. (As soon as I stuck it on the Vista box I could tell from its icon that the same problem would arise.) Does anyone here happen to know what one needs to do in order to have a useable patch.exe on Vista ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: NET SSH2 ppm for 5.10
- Original Message - From: Michael Ellery [EMAIL PROTECTED] To: 'perl-win32-users' perl-win32-users@listserv.ActiveState.com Sent: Thursday, September 25, 2008 5:24 AM Subject: NET SSH2 ppm for 5.10 does anyone know of a source for a NET::SSH2 ppm for 5.10? I managed to get this from uwinnipeg for 5.8, but ppm is telling me it can't find it in the 5.10 repository (now that I've upgraded). This has been a troublesome beast to build on Win32 for perl-5.10.0. But, after some minor patching ( http://rt.cpan.org/Public/Bug/Display.html?id=36614 ) I managed to build it on ActivePerl 1004 (perl -5.10.0). I'll send it over to Randy Kobes, and it will probably appear on the uwinnipeg 5.10 rep in the next few days (depending upon how busy Randy is with other stuff). In the meantime, Michael, let me know if you would like me to email the ppm over to you, off list. (It's a bit less than 700kb.) It was a very strange thing to build. On many of my perl builds I get a fatal error of the type: - C:\_32\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: C:\_32\mingw\lib\libkernel32.a(duces00221.o): illegal symbol index 1818586738 in relocs collect2: ld returned 1 exit status dmake: Error code 129, while making 'blib\arch\auto\Net\SSH2\SSH2.dll' - The name of the object file quoted in the message can change from one perl build to the next - but the error is otherwise identical. I have no idea what it means. One would suspect that it's the compiler (or libkernel32.a) that's at fault, but the very same compiler builds the very same source just fine on ActivePerl 1004. Beats me !!! Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Beginner Problems working with spaced filenames and directories on win
- Original Message - From: Dennis Daupert [EMAIL PROTECTED] The script has a problem when it hits a directory or filename containing spaces. Hi Dennis, I can't reproduce your specific problem: -- C:\_32perl -e $d='C:/Users/Rob/Saved Games';print -d $d 1 C:\_32perl -e $d='C:\Users\Rob\Saved Games';print -d $d 1 C:\_32perl -e $d='C:\Users\Rob\Saved';print -d $d C:\_32perl -e $d='C:/Users/Rob/Saved';print -d $d C:\_32perl -e $d='C:/Users/Rob/Saved Rubbish';print -d $d C:\_32perl -e $d='C:\Users\Rob\Saved Rubbish';print -d $d C:\_32 -- 'C:/Users/Rob/Saved Games' exists on my machine, but the other directories tested do not. The above output is entirely as expected. Probably best if you could provide a small standalone script (or one liner) that we can all run, and that demonstrates the problem. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Run perl on window using cygwin+Eclipse+EPIC
- Original Message -
From: Jing LI [EMAIL PROTECTED]
.
.
It uses find to find a type of file in a directory and its subdirectories:
my @jarfiles = split(' ',`find $bin_location -name *.jar`);
But when run or debug it in Eclipse, it has error:
sh: find: No such file or directory.
I believe that error message is being produced by your
C:/cygwin/bin/find.exe - which means that find.exe is being found ok. The
problem appears to be that the directory $bin_location is not being found.
What does the variable $bin_location contain ? If it's a location that means
something only to Cygwin (such as anything that begins with /usr,
/cygdrive/c, or ~/) then it probably needs to be changed into a location
that windows can make sense of.
Sorry - I don't know what eclipse is.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: perl download a winzip file from URL
- Original Message -
From: David M. Funk [EMAIL PROTECTED]
.
.
How do I remove the headers or is there a better way to d/l a binary file?
Not sure ... I'd try something like (untested):
$response = $ua-get($url);
open COPY, , my_copy.zip or die $!;
binmode(COPY);
if ($response-is_success) {
print COPY $response-content;
}
else {
die $response-status_line;
}
close COPY or die $!;
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Run perl on window using cygwin+Eclipse+EPIC
- Original Message -
From: Brian Raven [EMAIL PROTECTED]
To: perl-win32-users@listserv.ActiveState.com
Sent: Wednesday, September 10, 2008 11:33 PM
Subject: RE: Run perl on window using cygwin+Eclipse+EPIC
Sisyphus wrote:
- Original Message -
From: Jing LI [EMAIL PROTECTED] .
.
It uses find to find a type of file in a directory and its
subdirectories:
my @jarfiles = split(' ',`find $bin_location -name *.jar`);
But when run or debug it in Eclipse, it has error:
sh: find: No such file or directory.
I believe that error message is being produced by your
C:/cygwin/bin/find.exe - which means that find.exe is being found ok.
The problem appears to be that the directory $bin_location is not
being found.
I don't think so.
Yes, you're right.
If that were the case I would expect the error message
to be something like find: fred: No such file or directory. That it
starts sh: suggests that is coming from the shell, or something
pretending to be the shell. What I find puzzling is that if the shell
could not find the find executable, I would expect to see something like
sh: find: command not found.
Perhaps with the 'sh find' command, 'sh' expects to find a script called
'find'. When it fails to find that script (since no file named 'find'
exists), it then complains No such file or directory.
[EMAIL PROTECTED] ~
$ sh find
sh: /usr/bin/find: No such file or directory
[EMAIL PROTECTED] ~
$ sh find.exe
/usr/bin/find.exe: /usr/bin/find.exe: cannot execute binary file
[EMAIL PROTECTED] ~
Even that confuses me - because of the /usr/bin/ prefixing that's
happening.
But Cygwin *always* confuses me ... which is the reason that I avoid it
wherever possible.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Audio::Data
- Original Message - From: Mary [EMAIL PROTECTED] To: perl-win32-users@listserv.ActiveState.com Sent: Wednesday, September 10, 2008 7:38 AM Subject: Audio::Data Hello everybody, I hope I am posting on the right list. Cygwin list is probably more appropriate for this problem - I see you've also posted there, anyway :-) I am trying to run a program called rsynth which needs the Audio::Data module and I have not been able to install it with MCPAN. The package is found but the compilation fails: CPAN.pm: Going to build N/NI/NI-S/Audio-1.029.tar.gz Checking if your kit is complete... Looks good Writing Makefile for Audio::Data ERROR from evaluation of /home/Mary/.cpan/build/Audio-1.029-vjksgS/Play/Makefile.PL: Cannot open config/dummy.xs:No such file or directory at ./Makefile.PL line 54. In Play/Makefile.PL, the variable $driver is initially set to 'dummy' - and then changed depending upon the operating system that is detected. But there's no test to detect Cygwin, so the variable stays set to 'dummy' - which is apparently not what you want. I don't know how to fix this problem. Maybe in PLay/Makefile.PL you could set $driver to 'win32' and see how that goes. README.porting (in the source distro) has this to say: -- To add/fix drivers look at Play/Makefile.PL to see how the architecture specific sub-class is built. Then edit Play/config/* and re-run Makefile.PL Only Play/config/sun* have been tested Play/config/next* have been fully converted Rest of Play/config/* are really .c files from rsynth-2.0 and need coberting to true .xs files. -- And that's about all I could find. Looks like you'll need to build by hand (Perl Makefile.PL, make test, make install) rather than use the automated CPAN.pm procedure. It wouldn't build for me on native Win32. During the 'make' stage I got: --- ../config/mmsystem.h:64: error: redefinition of `struct waveformat_tag' ../config/mmsystem.h:73: error: redefinition of `struct pcmwaveformat_tag' ../config/mmsystem.h:79: error: redefinition of `struct tagWAVEOUTCAPSA' ../config/mmsystem.h:92: error: redefinition of `struct tagWAVEOUTCAPSW' ../config/mmsystem.h:122: error: redefinition of `struct tWAVEFORMATEX' ../config/mmsystem.h:137: error: redefinition of `struct mmtime_tag' --- Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ActiveState releases ActivePerl 5.8.8.824 and ActivePerl 5.10.0.1004
- Original Message - From: Jan Dubois [EMAIL PROTECTED] To: [EMAIL PROTECTED]; perl-win32-users@listserv.ActiveState.com Sent: Saturday, September 06, 2008 8:07 AM Subject: ActiveState releases ActivePerl 5.8.8.824 and ActivePerl 5.10.0.1004 ActiveState is pleased to announce ActivePerl 5.8.8 build 824 and ActivePerl 5.10.0 Build 1004, complete, ready-to-install Perl distributions for Windows, Mac OS X, Linux, Solaris, and AIX. I'm having a spot of bother with the 1004 x64 zip (AS package) at http://activestate.com/store/download_file.aspx?binGUID=49d6586c-86f5-413b-a4d9-8bd60d0e4b5f The download provides me with a 128 kb file which, when I try to unzip, produces the following error: --- Archive: ActivePerl-5.10.0.1004-MSWin32-x64-287188.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: can't find zipfile directory in ActivePerl-5.10.0.1004-MSWin32-x64-287188.zip, and can't find ActivePerl-5.10.0.1004-MSWin32-x64-287188.zip.zip, period. --- The other 2 AS packages that I downloaded (824 x86 and 1004 x86) were fine. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ActiveState releases ActivePerl 5.8.8.824 and ActivePerl 5.10.0.1004
- Original Message - From: Jan Dubois [EMAIL PROTECTED] . . The download provides me with a 128 kb file which, when I try to unzip, produces the following error: Your download must have been interrupted. I just downloaded from the link you provided above and received a zip file of 16,004,631 bytes that unzipped without problems. Yes, it's now working ok for me, too. I had made 2 attempts, about 10 minutes apart, to download the file and got the same result both times not sure how I (mis)managed that. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Difference between package repositories
- Original Message - From: Andrew Black [EMAIL PROTECTED] To: perl-win32-users@listserv.ActiveState.com Sent: Monday, August 25, 2008 10:45 PM Subject: Difference between package repositories Can someone explain how PPM repostitories work. If you go to http://cpan.uwinnipeg.ca you get repostitories at ActiveState www.bribes.org tcool.org trouchelle.com uwinnipeg Under which circumstances should you use which repository. I guess Activestate provide a stable version and other repositories more bleeding edge? ActiveState use a fully automated procedure to create their PPM packages. The other reps are more inclined to build PPM's that need a little manual intervention, or that need a C library that ActiveState haven't installed - so you'll often find PPM's on one or more of the other reps that don't exist on the ActiveState rep. Conversely, those other reps are generally not going to bother to provide something that's available on the ActiveState rep - so you'll also find PPM's on the ActiveState rep that don't exist on any other rep. Just use the first rep you find that provides the package you want. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::Lanman and Perl 5.10
- Original Message - From: Jan Dubois [EMAIL PROTECTED] To: 'Bullock, Howard A.' [EMAIL PROTECTED] Cc: perl-win32-users@listserv.ActiveState.com Sent: Thursday, August 21, 2008 5:39 AM Subject: RE: Win32::Lanman and Perl 5.10 Oops, should have been more careful before replying. Looks like Jens's modules are all pure GPL and not same terms as Perl. That makes me somewhat less interested in spending time on them. But, once you get co-maintainership, won't you be able to rewrite the license ? Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Problem with lanman
- Original Message - From: Barry Brevik [EMAIL PROTECTED] To: perl-win32-users@listserv.ActiveState.com Sent: Thursday, August 07, 2008 7:36 AM Subject: Problem with lanman I'm runing Perl v5.8.8 build 819 on Windows XP. I'm all excited about a couple of books I bought: Win32 Perl Programming the Standard Extensions, and Win32 Perl Scripting the Administrator's Handbook. Some of the sample code from the book have: use Win32::NetAdmin; ...at the beginning of the program. I have no trouble with those programs. However, some of the examples have: use Win32::Lanman; The very presence of that line causes my program to crash immediately with that ubiquitous Windows 2-tone gray dialog saying that Perl has committed a heinous crime, etc. Perl itself never issues any error despite use strict; use warnings;, and the cmd window is never closed. How did you install it ? There's a PPM for it at the bribes repository that could be worth a try (assuming it's not what you've already got). Just: ppm remove Win32-Lanman and then: ppm install http://www.bribes.org/perl/ppm/Win32-Lanman.ppd There's also a PPM (at the same repository) for Win32API::Net which, according to its description is a Perl interface to the Windows NT LanManager API account management functions. It could be worth trying as an alternative to Win32::Lanman if all else fails: ppm install http://www.bribes.org/perl/ppm/Win32API-Net.ppd Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: portable GUIs
- Original Message - From: Glenn Linderman [EMAIL PROTECTED] So it looks like Windows perl users are not portable perl users, from the dearth of responses to this message (on on-list, one off-list). OpenGL any good ? There's a ppm for it (5.8 only) at http://graphcomp.com/opengl/index.cgi?v=0111s5m1r=s1m1 : ppm install http://graphcomp.com/opengl/ppm58/OpenGL.ppd Once installed, the test.pl from the opengl source distro on cpan provides a nice demo. (That's all I've done as far as testing is concerned.) Works fine for me on perl 5.8, and I've also built it for perl 5.10 where it works just as well. Not sure if that's relevant to your needs. Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::Lanman make computer go argh!
- Original Message - From: Barry Brevik [EMAIL PROTECTED] . My test program begins like this: use Win32; use Win32::NetAdmin; use Win32::Lanman; As soon as it hits use Win32::Lanman, a gui dialog pops up which starts like this: Perl Command Line Interpreter has encountered a problem and needs to close. We are sorry for the inconvenience. . I would appreciate any clues as to where to start looking to fix this problem. Is any error message printed to the console as well (either before or after you close the gui box) ? Do you get the same behaviour by loading Win32::Lanman only ? ie, does running the following produce the same behaviour: perl -MWin32::Lanman -e 1 Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: module to convert text to tiff ???
- Original Message - From: Mike Schleif [EMAIL PROTECTED] To: perl-win32-users mailing list perl-win32-users@listserv.ActiveState.com Sent: Monday, June 23, 2008 9:41 AM Subject: module to convert text to tiff ??? Try googling for 'text2tiff' and 'txt2tiff'. I don't know if the stuff you'll turn up is any good. And I'm not sure that there's a ready made perl solution there - you might have to write the interface yourself ... or use system(). Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Unable to find Date::Calc in the ActiveState Package Repository
- Original Message - From: Leblanc, Larry [EMAIL PROTECTED] . . I was wondering why the Date::Calc package is nowhere to be found in the ActiveState Package Repository I think that ActiveState generally don't provide ppm packages of modules that ship with ActivePerl - and Date::Calc comes as standard with ActivePerl. (At least it does with build 1003 - I'm assuming the same holds for build 1002.) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: urgent help : Error while installing Crypt::DES at Windows XP
- Original Message - From: [EMAIL PROTECTED] . . C:\Perl\lib\CORE\perl.h(587) : fatal error C1083: Cannot open include file: 'sys/types.h': No such file or directory . - That's the (current) problem - the C headers aren't being found. With the versions of Visual Studio that I have (versions 6.0 and 7.0) there's a batch file in the compiler's bin folder named vcvars32.bat. Executing that file from the command prompt sets up the various environment variables so that things work correctly. That is, assuming that your compiler has a vcvars32.bat in its bin folder, and that your compiler's bin folder is already in your path, then it should just be a matter of entering vcvars32.bat (without the quotes, of course) at the command prompt. Then run nmake test - followed by nmake install (if everything works ok). Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: [C/XS] Strange problem with LoadLibrary and VC 7.0
- Original Message -
From: Sisyphus [EMAIL PROTECTED]
To: perl-win32-users perl-win32-users@listserv.ActiveState.com
Sent: Sunday, June 01, 2008 10:29 PM
Subject: [C/XS] Strange problem with LoadLibrary and VC 7.0
I realise I'm probably only talking to myself here ... it's a sign of
madness, I believe.
For the record, however, it seems that either Microsoft Visual Studio 7.0
.NET (Enterprise Architect Edition), or the perl that it builds, is flawed.
I can't fault the compiler in terms of C programs that emulate what I'm
trying to do in perl - so it's more'n'likely that it's perl that's flawed.
Probably not worth bothering about, given the small number (one, so far)
that have been affected by this.
I finally rewrote the test script as:
-
use warnings;
use Win32;
use Inline C = Config =
BUILD_NOISY = 1;
use Inline C = 'EOC';
typedef double (CALLBACK* FUNC2)(int);
SV * bar(SV * dll, SV * func, SV * x) {
HMODULE hinstLib;
FUNC2 ProcAdd;
BOOL freelib, fRunTimeLinkSuccess = FALSE;
double ret = 0;
hinstLib = LoadLibrary((LPCTSTR)SvPV_nolen(dll));
if (hinstLib != NULL) {
ProcAdd = (FUNC2) GetProcAddress(hinstLib,
(LPCSTR)SvPV_nolen(func));
if (fRunTimeLinkSuccess = (ProcAdd != NULL)) {
ret = ProcAdd((int)SvIV(x));
}
else printf(GetProcAddress() failed\n);
freelib = FreeLibrary(hinstLib);
printf(freelib: %d\nreturn: %f\n, freelib, ret);
return newSVnv(ret);
}
else {
printf(LoadLibrary() failed\n);
return newSVnv(ret);
}
}
EOC
$z = bar(mydll, d_one_arg, 123);
print $z, \n;
-
With the MinGW compiler that correctly outputs:
freelib: 1
return: 17.571429
17.5714285714286
With VC 7.0, I get:
freelib: 1
return: 17.571429
Use of uninitialized value $z in print at try.pl line 41.
In other words, with VC 7.0, up to and including the following line of code
in the xsub, everything works fine and as expected:
printf(freelib: %d\nreturn: %f\n, freelib, ret);
The very next line of code after that is:
return newSVnv(ret);
and that line obviously either fails to return anything or returns undef. If
return newSVnv(ret); can't function correctly, then I'm just wasting my
time thinking about it.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
[C/XS] Strange problem with LoadLibrary and VC 7.0
Hi,
(This almost certainly has little, if anything, to do with perl.)
I have (a commercial version of) VC 7.0, and a perl-5.10.0 built using that
compiler.
I also have MinGW, and a perl-5.10.0 built using that MinGW compiler.
I have a test dll (named mydll.dll) that exports a function named
'd_one_arg'.
That function takes a single 'int' arg, and returns the value of that int
divided by 7. (The return value is a double.)
In a nutshell, there's no problem with MinGW, but with VC 7.0 the following
Inline::C script always segfaults around the time that the foo() function
exits:
use warnings;
use Inline C = Config =
BUILD_NOISY = 1;
use Inline C = 'EOC';
typedef double (CALLBACK* FUNC2)(int);
SV * load_library (SV * dll) {
return newSVuv((HMODULE)LoadLibrary((LPCTSTR)SvPV_nolen(dll)));
}
SV * foo(SV * x, SV * hinstLib) {
FUNC2 ProcAdd;
BOOL freelib, fRunTimeLinkSuccess = FALSE;
double ret = 0;
if ((HMODULE)SvUV(hinstLib) != NULL) {
ProcAdd = (FUNC2) GetProcAddress((HMODULE)SvUV(hinstLib),
d_one_arg);
if (fRunTimeLinkSuccess = (ProcAdd != NULL)) {
ret = ProcAdd((int)SvIV(x));
}
else printf(GetProcAddress() failed\n);
freelib = FreeLibrary((HMODULE)SvUV(hinstLib));
printf(freelib: %d\nreturn: %f\n, freelib, ret);
return newSVnv(ret);
}
else {
printf(LoadLibrary() failed\n);
return newSVnv(ret);
}
}
EOC
$lib = load_library(mydll);
$z = foo(123, $lib);
print $z, \n;
It makes no difference if $lib is instead assigned the return value of
Win32::LoadLibrary(mydll).
It makes no difference whether the dll was built using MinGW or VC 7.0.
Running that script in the VC 7.0 environment produces:
freelib: 1
return: 17.571429
[Then a segfault]
So, I'm thinking the segfault is caused by either:
a) 'return newSVnv(ret);'
or
b) the exiting of the foo() function;
or
c)'print $z, \n;'
If I rewrite foo() so that it loads the mydll.dll library itself (instead of
taking a handle to it as its second arg) then there's no problem. That is,
there's no problem if foo() looks like:
---
SV * foo(SV * x) {
HMODULE hinstLib;
FUNC2 ProcAdd;
BOOL freelib, fRunTimeLinkSuccess = FALSE;
double ret = 0;
hinstLib = LoadLibrary(mydll);
if (hinstLib != NULL) {
ProcAdd = (FUNC2) GetProcAddress(hinstLib, d_one_arg);
if (fRunTimeLinkSuccess = (ProcAdd != NULL)) {
ret = ProcAdd((int)SvIV(x));
}
else printf(GetProcAddress() failed\n);
freelib = FreeLibrary(hinstLib);
printf(freelib: %d\nreturn: %f\n, freelib, ret);
return newSVnv(ret);
}
else {
printf(LoadLibrary() failed\n);
return newSVnv(ret);
}
}
---
That (correctly) produces:
freelib: 1
return: 17.571429
17.5714285714286
So what is it that causes the first version of foo() to segfault ?
(I've also tried things out on a perl-5.8.8 built with the VC 7.0 compiler,
and the behaviour there is exactly the same as for 5.10.0.)
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
[OT] How to build a dll that Win32::API can access.
Hi,
I'm having awful trouble trying to build a simple dll that Win32::API can
access. I have version 0.53 of Win32::API, and perl-5.10.0 (built from
source using the same (commercial version of) Visual Studio 7.0 compiler
that I'm using to build the dll.
Here's one of the things that I've tried:
--- integer.h --
int my_int(int);
--- integer.c --
#include integer.h
int my_int(int x) {
return x / 7;
}
Build the dll (with __stdcall calling convention):
C:\_32\ccl /Gz /LD integer.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
integer.c
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.
/out:integer.dll
/dll
/implib:integer.lib
integer.obj
C:\_32\c
Write a script to access the dll's my_int function:
-- integer.pl --
use Win32::API;
use warnings;
$function = Win32::API-new('integer', 'my_int', 'N', 'N');
if(!$function) {print $^E, \n}
$ret = $function-Call(123);
print $ret, \n;
Run integer.pl:
C:\_32\cperl integer.pl
The specified procedure could not be found
Can't call method Call on an undefined value at integer.pl line 6.
C:\_32\c
What am I missing ?
Does integer.dll need to export the my_int function ?
It doesn't export any symbols at all, so I've also tried building with
__declspec(dllexport). The dll then exports '_my_int' (which has a leading
underscore) and the output of running integer.pl remains unchanged.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: ActivePerl 5.10.0 Build 1003 released
- Original Message -
From: Jan Dubois [EMAIL PROTECTED]
To: [EMAIL PROTECTED];
perl-win32-users@listserv.ActiveState.com; [EMAIL PROTECTED]
Sent: Saturday, May 17, 2008 8:59 AM
Subject: ActivePerl 5.10.0 Build 1003 released
ActiveState is pleased to announce ActivePerl 5.10.0 Build 1003
There's a minor nit with building modules on this build of perl. If
Math::BigInt::GMP is not installed, you'll get the following message every
time you run nmake/dmake:
Math::BigInt: couldn't load specified math lib(s), fallback to
Math::BigInt::FastCalc at C:/ap1003/lib/Win32API/File.pm line 20
Everything still works ok - it's just a little mystifying when you first see
it, that's all.
It's all because of this code in Win32API/File.pm (version 0.1001 only,
afaict):
# Math::BigInt optimizations courtesy of Tels
BEGIN {
require Math::BigInt;
if (defined($Math::BigInt::VERSION) $Math::BigInt::VERSION = 1.60) {
Math::BigInt-import(lib = 'GMP');
}
}
My other builds of perl 5.10.0 (and a recent 5.11.0 snapshot) have version
0.1001_01 which doesn't try to load Math::BigInt::GMP and therefore doesn't
throw up that message. I guess the simple solution is for ActiveState to
avoid version 0.1001 in future releases.
I see the problem has already been reported at
http://rt.cpan.org/Public/Dist/Display.html?Name=Win32API-File (6 months
ago) and that future releases of Win32API-File will address this issue. I'm
not sure where version 0.1001_01 comes from, but I guess it is one such
future release.
I don't recall seeing the message with build 1002, so I'm guessing it used
version 0.1001_01 and that somehow version 0.1001 has found its way into
build 1003.
Cheers,
Rob
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::Process::Create
- Original Message - From: Michael Ellery [EMAIL PROTECTED] To: 'perl-win32-users' perl-win32-users@listserv.ActiveState.com Sent: Tuesday, April 29, 2008 5:24 AM Subject: Win32::Process::Create ..I use this function pretty regularly to spawn procs on windows, but I've often wanted to minimize the console or main window that was launched. Does anyone know how to do this? In the corresponding WIN32 API, there is a STARTUPINFO structure that allows this, but looks like it's not part of the Win32::Process API. Advice appreciated. Jst a couple of thoughts - I don't have time to test any of this out at the moment. What happens if you launch the script using the wperl executable instead of the perl executable ? Have you checked the various flags constants ? From the docs: -- EXPORTS The following constants are exported by default: CREATE_DEFAULT_ERROR_MODE CREATE_NEW_CONSOLE CREATE_NEW_PROCESS_GROUP CREATE_NO_WINDOW CREATE_SEPARATE_WOW_VDM CREATE_SUSPENDED CREATE_UNICODE_ENVIRONMENT DEBUG_ONLY_THIS_PROCESS DEBUG_PROCESS DETACHED_PROCESS HIGH_PRIORITY_CLASS IDLE_PRIORITY_CLASS INFINITE NORMAL_PRIORITY_CLASS REALTIME_PRIORITY_CLASS THREAD_PRIORITY_ABOVE_NORMAL THREAD_PRIORITY_BELOW_NORMAL THREAD_PRIORITY_ERROR_RETURN THREAD_PRIORITY_HIGHEST THREAD_PRIORITY_IDLE THREAD_PRIORITY_LOWEST THREAD_PRIORITY_NORMAL THREAD_PRIORITY_TIME_CRITICAL The following additional constants are exported by request only: STILL_ACTIVE -- I was thinking specifically of CREATE_NO_WINDOW constant (but perhaps that does something else). Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: rsync for Win32
Sisyphus wrote: Hi, On the face of it, the topic of this post has little (if anything) to do with perl. But, afaict from 'perldoc perlhack', if I want to stay in touch with the current perl developments I need to be able to download the latest source by running: rsync -avz rsync://public.activestate.com/perl-current/ As was pointed out to me (off-list) the above command will result in a list of files, but none of those files will be downloaded. A trailing . is needed if the files are to be downloaded to the cwd. I got bitten by that. (That was my first mistake.) I ran it without the trailing . (as perl 'perldoc perlhack') ... saw the list of files, and spent a good few minutes trying to work out where the hell they had been placed :-) Someone had sent me a self-contained rsync package that seemed to work quite well (once I got the command sorted out). That package came with its own cygwin dll, so I deduced it was in fact a cygwin build, and that if I was going to use Cygwin's rsync, I might as well incorporate it into my Cygwin installation. (That was my second mistake.) I finally realised that the list of available Cygwin packages I had been looking at contained only the packages that I had already downloaded and stored locally. The 'rsync' package wasn't listed there simply because I had never downloaded it !! So ... I eventually got round to re-running Cygwin's Setup.exe - the aim being to install both git and rsync into Cygwin. Unfortunately I selected Install from internet instead of just downloading the files into my local folder and then installing from that local folder. (That was my third mistake.) I expected that Install from internet was simply going to install 'rsync' and 'git' - since (I thought) that was all I was asking it to do. (That was my fourth mistake.) Instead it started installing packages (such as perl) that I already had. Unfortunately, part of the way through, the process hanged ... so I hit the Cancel button. (That would have been my fifth mistake, except that I don't see that I had any other option.) I then found that things like running 'perl -V' from the Cygwin shell died (with errors that I can no longer recall). Only thing I could then think of doing was to try another total Install from internet from a different mirror - which I did. But ... apparently, if you cancel a Setup.exe installation before it has completed ( as I had done), then the next time you run Setup.exe you're liable to get a segmentation fault part way through (which is exactly what happened to me). I've since found that there's a patched Setup.exe (that doesn't suffer this affliction) available from http://rapidshare.com/files/98717404/setup.exe By this time I couldn't even open up Cygwin's bash shell ... so I simply deleted everything to do with Cygwin and started again from scratch, making sure to install both rsync and git. That seems to have worked quite well, except that I've now got a lot of stuff to rebuild (unless I can Restore it from the Recycle Bin - to where the original installation was sent.) Now this sort of experience is pretty much standard for me wrt Cygwin ... which is the reason that I try to avoid it wherever possible. Had I have known about the source snapshots (tarballs) available at http://public.activestate.com/pub/apc/perl-current-snap/ , I wouldn't even have bothered with rsync to begin with. Thanks to all respondents, btw. It's to be noted that, with your assistance, and despite my own inadequacies, I have actually managed to get there in the end. (It now just remains for me to determine exactly where there is :-) Cheers, Rob ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
