Re: gcc for building Perl on WinXP

[Chris Marshall]

It would really simplify things for win32 PDL if an easy,
1-click addition for gfortran were available.  We're spending
a lot of development time working around the lack of a
fortran compiler on win32 perls.  Since gcc includes one,
it is more of a packaging and distribution issue than one
of existence.

Cheers,
Chris

On Sun, Oct 30, 2011 at 3:52 PM, Karel Miko  wrote:
>
>> In preparing the next Strawberry release you've no doubt noticed that
>> mingw-w64 32bit version cannot build a working Perl after gcc version 4.4.3
>> on Windows XP.
>
> Yes, in fact it was during the last week when we have found out (with help
> of BinGOs and Ranguard via IRC) that gcc-4.4.7 and 4.6.1 (not only with
> mingw-w64 runtime but also with mingw.org's runtime) produce perl binaries
> that crash on Windows XP.
>
> For strawberry perl 5.14.2.0 we have decided to use:
> - on 32 bit version gcc-4.4.3 (with slightly old mingw-w64 runtime)
>
>  http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-20100123-kmx-v3.zip
> - on 64 bit version gcc-4.4.7(prereleae) (with mingw-w64 runtime 1.0.1)
>
>  http://strawberryperl.com/package/kmx/64_gcctoolchain/mingw64-w64-gcc4.4.7(pre)_20111014.zip
>
>
>> Commit 180422 to the 4.6 branch of gcc fixes the problem - I've cross
>> compiled my own 32bit 4.6.2 release (the tagged 4.6.2 release includes this
>> fix) which compiles a working Perl 5.14.2 on Windows XP.
>
> Many thanks , this is a valuable piece of information for me as I was in
> doubts where to start reporting/discussing the issue, now it is clear.
>
>
>> For my own use, I need to move to 4.6.2 as 4.4.7 cannot compile wxWidgets
>> 2.9.x branch.
>>
>> As a side benefit I also get an up to date v2 mingw-w64 crt.
>>
>> I'll be publishing source, patches and build instructions at
>>
>> http://perlmingw.sourceforge.net/
>>
>> (plus, of course, the compiled releases).
>> The patches are just the minimum necessary from sezero build and TDM GCC
>> builds to get a working dist.
>>
>> Just a thought, but it might be nice if we had a sort of 'standard' gcc
>> for Perl on Windows.
>
> Why not. As for my opinion concerning gcc toolchain included in strawberry
> perl:
> - we would strongly prefer to use mingw-w64 (not mingw.org) runtime for both
> 32/64bit
> - we have no special preference as for the gcc version (but versions like
> gcc-X.Y.0 are perhaps too "in development" for us)
> - we need gcc toolchain supporting /include and /lib
> directories in search paths (without explicit -I or -L options)
> - we would appreciate gcc toolchain with frotran (maybe a kind of addon or
> extra package) as it comes handy to PDL guys using strawberry
>
>
>>
>> Anyhow, I think you could just backport the fix to the current 4.4.7
>> branch. But, for what it is worth, Strawberry users will be unable to
>> compile wxWidgets 2.9.x branches (without some patching at least)
>
> OK, I take it as your "gcc upgrade" request - we will probably aim at
> gcc-4.6.2 + mingw-w64 runtime (v2 or latest v2RC)
>
> However, currently the release candidates for strawberry 5.14.2.0 are IMHO
> too good to let them fall on the floor. I think that the updated
> gcc-toolchain cannot be expected sonner than in 5.14.2.1 (don't ask me when
> as our release schedule is slightly demolished - as you have probably
> noticed)
>
> BTW for all that might be interested - latest RC's are available at:
> http://strawberryperl.com/package/kmx/p5.14.2.0-RC/
>
>
> --
> kmx
>

Re: gcc for building Perl on WinXP

[Chris Marshall]

We've tested the PDL pthread support with "POSIX Threads
(pthreads) for Win32" at http://sourceware.org/pthreads-win32/ .
It is nice because it allows PDL computations to make use
of multicore processors for calculations.  Always nice to see
those factors of 2X, 4X, 6X, or more in speedup

--Chris

On Wed, Nov 2, 2011 at 9:30 PM, Sisyphus  wrote:
>
> - Original Message - From: "kmx"
>
>> As for the future gcc-4.6.2 toolchain there is also an interesting
>> question about including pthreads or winpthreads support as PDL is AFAIK
>> somohow able to handle threads this way (not sure if this is valid for
>> Win32)
>
> Yes, pthreads works with PDL on Win32.
> There's a crash in one of PDL's pthread test scripts that needs to be sorted
> out, but the basic functionality seems to be fine.
>
> Cheers,
> Rob
>

Re: gcc for building Perl on WinXP

[Chris Marshall]

I just pushed a new PDL git with a fix for the perl
vs POSIX threads namespace/implementation collision.
You should be able to build with the unedited pthread.h
now

--Chris

On Sun, Nov 6, 2011 at 5:58 PM, chm  wrote:
> dmake test passed all except the known problem
> with t/pthreadBarf.t.  Also, I think we can fix
> the breakage in pthread.h by doing the undef
> in our pdlmagic file that is including pthread.h.
>
> Cheers,
> Chris
>
> On 11/6/2011 5:40 PM, chm wrote:
>>
>> I got it to work with the following:
>>
>> Add after the POSIX Threads comment block in pthread.h:
>>
>>> #ifdef PTHREAD_CREATE_JOINABLE
>>> #undef PTHREAD_CREATE_JOINABLE
>>> #endif
>>
>> in order to remedy the fact that perl has added a macro
>> with the same value. If the pthread one is not already
>> defined then the perl one is---but this breaks the w32
>> pthreads include file.
>>
>> Then set the parameters in perldl.conf to
>>
>>> WITH_POSIX_THREADS => 1,
>>>
>>> POSIX_THREADS_INC => undef, # '-I/usr/pthread/include'
>>> POSIX_THREADS_LIBS => '-lpthread', # '-L/usr/pthread -lpthreadGC2'
>>
>> It is building away as I type. Will let you know how
>> dmake test comes out
>>
>> --Chris
>>
>>
>> On 11/6/2011 4:31 PM, chm wrote:
>>>
>>> Hi kmx-
>>>
>>> The detection for the pthread library is currently broken.
>>> To build PDL with pthreads you'll need to explicitly set
>>> the values of WITH_POSIX_THREADS, POSIX_THREADS_INC, and
>>> POSIX_THREADS_LIBS where the comment indicate what worked
>>> for my strawberry perl install was:
>>>
>>>> WITH_POSIX_THREADS => undef,
>>>>
>>>> POSIX_THREADS_LIBS => '-LC:/chm/strawberry/pthreads/lib -lpthreadGC2',
>>>> POSIX_THREADS_INC => '-IC:/chm/strawberry/pthreads/include',
>>>
>>> and the C:/chm/strawberry/pthreads contained the pthreads
>>> install location. I'm actually working on the detection
>>> code this evening so that if a pthread library is in the
>>> correct location it would be detected and used.
>>>
>>> I'll give your library a build try this evening if I can.
>>>
>>> Cheers,
>>> Chris
>>>
>>>
>>> On 11/6/2011 4:14 PM, kmx wrote:
>>>>
>>>> Chris and/or Rob,
>>>>
>>>> could you please try the following:
>>>>
>>>> 1/ take
>>>>
>>>> http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip
>>>>
>>>>
>>>>
>>>>
>>>> 2/ take
>>>>
>>>> http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip
>>>>
>>>>
>>>>
>>>> (unzip into the same dir as 1/)
>>>>
>>>> 3/ try to build PDL with pthreads support
>>>>
>>>> My quick test failed during PDL installation (but it was really a quick
>>>> shot)
>>>>
>>>> Any feedback welcome
>>>>
>>>> --
>>>> kmx
>>>>
>>>> On 3.11.2011 14:13, Chris Marshall wrote:
>>>>>
>>>>> We've tested the PDL pthread support with "POSIX Threads
>>>>> (pthreads) for Win32" at http://sourceware.org/pthreads-win32/ .
>>>>> It is nice because it allows PDL computations to make use
>>>>> of multicore processors for calculations. Always nice to see
>>>>> those factors of 2X, 4X, 6X, or more in speedup
>>>>>
>>>>> --Chris
>>>>>
>>>>> On Wed, Nov 2, 2011 at 9:30 PM, Sisyphus
>>>>> wrote:
>>>>>>
>>>>>> - Original Message - From: "kmx"
>>>>>>>
>>>>>>> As for the future gcc-4.6.2 toolchain there is also an interesting
>>>>>>> question about including pthreads or winpthreads support as PDL is
>>>>>>> AFAIK
>>>>>>> somohow able to handle threads this way (not sure if this is valid
>>>>>>> for
>>>>>>> Win32)
>>>>>>
>>>>>> Yes, pthreads works with PDL on Win32.
>>>>>> There's a crash in one of PDL's pthread test scripts that needs to be
>>>>>> sorted
>>>>>> out, but the basic functionality seems to be fine.
>>>>>>
>>>>>> Cheers,
>>>>>> Rob
>>
>>
>> -
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1411 / Virus Database: 2092/4000 - Release Date: 11/06/11
>>
>>
>
>

Re: gcc for building Perl on WinXP

[Chris Marshall]

Are you sure this is the latest PDL git from sf.net?
The error here looks like something that has already
been fixed as of CPAN developers release 2.4.9_008
according to the PDL Release_Notes.

--Chris

On Mon, Nov 7, 2011 at 4:07 PM, kmx  wrote:
> Chris,
>
> that sounds great, however my attempt ended up with:
>
> C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils\xsubpp
>  -typemap C:\strawberry\perl\lib\ExtUtils\typemap -typemap typemap  Core.xs
>> Core.xsc && C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e mv --
> Core.xsc Core.c
> Could not find a typemap for C type 'PDL_Long *' in Core.xs
>
> --
> kmx
>
> On 7.11.2011 20:40, Chris Marshall wrote:
>>
>> I just pushed a new PDL git with a fix for the perl
>> vs POSIX threads namespace/implementation collision.
>> You should be able to build with the unedited pthread.h
>> now
>>
>> --Chris
>>
>> On Sun, Nov 6, 2011 at 5:58 PM, chm  wrote:
>>
>>>
>>> dmake test passed all except the known problem
>>> with t/pthreadBarf.t.  Also, I think we can fix
>>> the breakage in pthread.h by doing the undef
>>> in our pdlmagic file that is including pthread.h.
>>>
>>> Cheers,
>>> Chris
>>>
>>> On 11/6/2011 5:40 PM, chm wrote:
>>>
>>>>
>>>> I got it to work with the following:
>>>>
>>>> Add after the POSIX Threads comment block in pthread.h:
>>>>
>>>>
>>>>>
>>>>> #ifdef PTHREAD_CREATE_JOINABLE
>>>>> #undef PTHREAD_CREATE_JOINABLE
>>>>> #endif
>>>>>
>>>>
>>>> in order to remedy the fact that perl has added a macro
>>>> with the same value. If the pthread one is not already
>>>> defined then the perl one is---but this breaks the w32
>>>> pthreads include file.
>>>>
>>>> Then set the parameters in perldl.conf to
>>>>
>>>>
>>>>>
>>>>> WITH_POSIX_THREADS =>  1,
>>>>>
>>>>> POSIX_THREADS_INC =>  undef, # '-I/usr/pthread/include'
>>>>> POSIX_THREADS_LIBS =>  '-lpthread', # '-L/usr/pthread -lpthreadGC2'
>>>>>
>>>>
>>>> It is building away as I type. Will let you know how
>>>> dmake test comes out
>>>>
>>>> --Chris
>>>>
>>>>
>>>> On 11/6/2011 4:31 PM, chm wrote:
>>>>
>>>>>
>>>>> Hi kmx-
>>>>>
>>>>> The detection for the pthread library is currently broken.
>>>>> To build PDL with pthreads you'll need to explicitly set
>>>>> the values of WITH_POSIX_THREADS, POSIX_THREADS_INC, and
>>>>> POSIX_THREADS_LIBS where the comment indicate what worked
>>>>> for my strawberry perl install was:
>>>>>
>>>>>
>>>>>>
>>>>>> WITH_POSIX_THREADS =>  undef,
>>>>>>
>>>>>> POSIX_THREADS_LIBS =>  '-LC:/chm/strawberry/pthreads/lib
>>>>>> -lpthreadGC2',
>>>>>> POSIX_THREADS_INC =>  '-IC:/chm/strawberry/pthreads/include',
>>>>>>
>>>>>
>>>>> and the C:/chm/strawberry/pthreads contained the pthreads
>>>>> install location. I'm actually working on the detection
>>>>> code this evening so that if a pthread library is in the
>>>>> correct location it would be detected and used.
>>>>>
>>>>> I'll give your library a build try this evening if I can.
>>>>>
>>>>> Cheers,
>>>>> Chris
>>>>>
>>>>>
>>>>> On 11/6/2011 4:14 PM, kmx wrote:
>>>>>
>>>>>>
>>>>>> Chris and/or Rob,
>>>>>>
>>>>>> could you please try the following:
>>>>>>
>>>>>> 1/ take
>>>>>>
>>>>>>
>>>>>> http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2/ take
>>>>>>
>>>>>>
>>>>>> http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip
>>>>>>
>>>>>>
>>>>>>
>>>>>> (unzip into the same dir as 1/)
>>>>>>
>>>>>> 3/ try to build PDL with pthreads support
>>>>>>
>>>>>> My quick test failed during PDL installation (but it was really a
>>>>>> quick
>>>>>> shot)
>>>>>>
>>>>>> Any feedback welcome
>>>>>>
>>>>>> --
>>>>>> kmx
>>>>>>
>>>>>> On 3.11.2011 14:13, Chris Marshall wrote:
>>>>>>
>>>>>>>
>>>>>>> We've tested the PDL pthread support with "POSIX Threads
>>>>>>> (pthreads) for Win32" at http://sourceware.org/pthreads-win32/ .
>>>>>>> It is nice because it allows PDL computations to make use
>>>>>>> of multicore processors for calculations. Always nice to see
>>>>>>> those factors of 2X, 4X, 6X, or more in speedup
>>>>>>>
>>>>>>> --Chris
>>>>>>>
>>>>>>> On Wed, Nov 2, 2011 at 9:30 PM, Sisyphus
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> - Original Message - From: "kmx"
>>>>>>>>
>>>>>>>>>
>>>>>>>>> As for the future gcc-4.6.2 toolchain there is also an interesting
>>>>>>>>> question about including pthreads or winpthreads support as PDL is
>>>>>>>>> AFAIK
>>>>>>>>> somohow able to handle threads this way (not sure if this is valid
>>>>>>>>> for
>>>>>>>>> Win32)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, pthreads works with PDL on Win32.
>>>>>>>> There's a crash in one of PDL's pthread test scripts that needs to
>>>>>>>> be
>>>>>>>> sorted
>>>>>>>> out, but the basic functionality seems to be fine.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Rob
>>>>>>>>
>>>>
>>>> -
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 10.0.1411 / Virus Database: 2092/4000 - Release Date: 11/06/11
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

Re: gcc for building Perl on WinXP

[Chris Marshall]

I just realized what might have happened.  You'll need
to do a dmake clean and then a complete build from
scratch to ensure that old copies of the various files
are not being used (some of these are generated at
the configure stage).

On Mon, Nov 7, 2011 at 4:20 PM, Chris Marshall  wrote:
> Are you sure this is the latest PDL git from sf.net?
> The error here looks like something that has already
> been fixed as of CPAN developers release 2.4.9_008
> according to the PDL Release_Notes.
>
> --Chris
>
> On Mon, Nov 7, 2011 at 4:07 PM, kmx  wrote:
>> Chris,
>>
>> that sounds great, however my attempt ended up with:
>>
>> C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils\xsubpp
>>  -typemap C:\strawberry\perl\lib\ExtUtils\typemap -typemap typemap  Core.xs
>>> Core.xsc && C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e mv --
>> Core.xsc Core.c
>> Could not find a typemap for C type 'PDL_Long *' in Core.xs
>>
>> --
>> kmx
>>
>> On 7.11.2011 20:40, Chris Marshall wrote:
>>>
>>> I just pushed a new PDL git with a fix for the perl
>>> vs POSIX threads namespace/implementation collision.
>>> You should be able to build with the unedited pthread.h
>>> now
>>>
>>> --Chris
>>>
>>> On Sun, Nov 6, 2011 at 5:58 PM, chm  wrote:
>>>
>>>>
>>>> dmake test passed all except the known problem
>>>> with t/pthreadBarf.t.  Also, I think we can fix
>>>> the breakage in pthread.h by doing the undef
>>>> in our pdlmagic file that is including pthread.h.
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> On 11/6/2011 5:40 PM, chm wrote:
>>>>
>>>>>
>>>>> I got it to work with the following:
>>>>>
>>>>> Add after the POSIX Threads comment block in pthread.h:
>>>>>
>>>>>
>>>>>>
>>>>>> #ifdef PTHREAD_CREATE_JOINABLE
>>>>>> #undef PTHREAD_CREATE_JOINABLE
>>>>>> #endif
>>>>>>
>>>>>
>>>>> in order to remedy the fact that perl has added a macro
>>>>> with the same value. If the pthread one is not already
>>>>> defined then the perl one is---but this breaks the w32
>>>>> pthreads include file.
>>>>>
>>>>> Then set the parameters in perldl.conf to
>>>>>
>>>>>
>>>>>>
>>>>>> WITH_POSIX_THREADS =>  1,
>>>>>>
>>>>>> POSIX_THREADS_INC =>  undef, # '-I/usr/pthread/include'
>>>>>> POSIX_THREADS_LIBS =>  '-lpthread', # '-L/usr/pthread -lpthreadGC2'
>>>>>>
>>>>>
>>>>> It is building away as I type. Will let you know how
>>>>> dmake test comes out
>>>>>
>>>>> --Chris
>>>>>
>>>>>
>>>>> On 11/6/2011 4:31 PM, chm wrote:
>>>>>
>>>>>>
>>>>>> Hi kmx-
>>>>>>
>>>>>> The detection for the pthread library is currently broken.
>>>>>> To build PDL with pthreads you'll need to explicitly set
>>>>>> the values of WITH_POSIX_THREADS, POSIX_THREADS_INC, and
>>>>>> POSIX_THREADS_LIBS where the comment indicate what worked
>>>>>> for my strawberry perl install was:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> WITH_POSIX_THREADS =>  undef,
>>>>>>>
>>>>>>> POSIX_THREADS_LIBS =>  '-LC:/chm/strawberry/pthreads/lib
>>>>>>> -lpthreadGC2',
>>>>>>> POSIX_THREADS_INC =>  '-IC:/chm/strawberry/pthreads/include',
>>>>>>>
>>>>>>
>>>>>> and the C:/chm/strawberry/pthreads contained the pthreads
>>>>>> install location. I'm actually working on the detection
>>>>>> code this evening so that if a pthread library is in the
>>>>>> correct location it would be detected and used.
>>>>>>
>>>>>> I'll give your library a build try this evening if I can.
>>>>>>
>>>>>> Cheers,
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> On 11/6/2011 4:14 PM, kmx wrote:
>>>>>>

Re: problems with strawberry perl portable and cpan

[Chris Marshall]

Hi kmx,

Thanks for the link, I hadn't realized that the official
release of 5.14 SPP was out.  I'll be sure to give it a
go.

BTW, it would be useful if the release notes on the
web site also included the output from 'perl -V' or is
there already somewhere to get that (without having
to install SP first)?

--Chris

On Thu, Apr 26, 2012 at 10:47 AM, kmx  wrote:
> On 25.4.2012 16:26, "René Staffen" wrote:
>> Hi,
>> I hope this is the right mailing list. it was linked from 
>> http://strawberryperl.com/support.html but its name does not sound related 
>> for me. Please inform me, it iam wrong.
>>
>> Beside this doubts here is my Problem:
>> i use a portable edition of strawberry but i got problems with cpan.
>> cpan always gives errors if perl is not present at the folder there i first 
>> used portable perl.
>> The errors are of kind 'file not found' because cpan looks in the old 
>> directory
>> eg:
>>> Das System kann den angegebenen Pfad nicht finden.
>>>   ADAMK/DBD-SQLite-1.35.tar.gz
>>>   
>>> E:\Development\Scripte\strawberry-perl-5.12.3.0-portable__\c\bin\dmake.exe 
>>> -- NOT OK
>> the current path is c:\strawberry-perl but may change because i also use 
>> this installation from USB-Stick
>>
>> i allready tried to delete the cpan/build folder but with no success.
>>
>> i allready installed many things so i do not want to start from clean 
>> installation
>>
>> Any hints?
>
> Please try strawberry perl portable 5.14.2.1 from release page
>  - portable 5.12.3 is buggy.
>
> --
> kmx

Re: problems with strawberry perl portable and cpan

[Chris Marshall]

Hi kmx-

Thanks for the perl -V info.

That appears to be from the 32bit SP.
Could you send the 64bit perl -V as well?

How difficult would it be for me to build
a 32bit SP with use64bit stuff enabled?

I'm working on true 64bit index/data size
support for PDL and a 32bit SP would be
a good intermediate test point since the
new addressing needs to work correctly
for 32bit perls, even if the hardware won't
actually let you address more than 4GB.

64bit PDL plus the recent work for memory
mapped file support will allow for some
very nice things for PDL on 64bit platforms.

--Chris

On Fri, Apr 27, 2012 at 11:12 AM, kmx  wrote:
>
>> BTW, it would be useful if the release notes on the
>> web site also included the output from 'perl -V'
>
> OK, I will consider it (FYI: I have already on my TODO list missing
> checksums for released ZIPs)
>
>
>> or is there already somewhere to get that (without having
>> to install SP first)?
>
> You can ask me :)
>
> d:\perl32>perl -V
> Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
>
>  Platform:
>    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
>    uname='Win32 strawberryperl 5.14.2.1-portable #1 Tue Nov 22 18:24:29
> 2011 i386'
>    config_args='undef'
>    hint=recommended, useposix=true, d_sigaction=undef
>    useithreads=define, usemultiplicity=define
>    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>    use64bitint=undef, use64bitall=undef, uselongdouble=undef
>    usemymalloc=n, bincompat5005=undef
>  Compiler:
>    cc='gcc', ccflags =' -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS
> -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
> -fno-strict-aliasing -mms-bitfields',
>    optimize='-s -O2',
>    cppflags='-DWIN32'
>    ccversion='', gccversion='4.4.7', gccosandvers=''
>    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
>    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
>    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long',
> lseeksize=8
>    alignbytes=8, prototype=define
>  Linker and Libraries:
>    ld='g++.exe', ldflags ='-s -L"D:\perl32\perl\lib\CORE" -L"D:\perl32\c\lib"'
>    libpth=D:\perl32\c\lib D:\perl32\c\i686-w64-mingw32\lib
>    libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
> -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
> -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
>    perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
> -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
> -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
>    libc=, so=dll, useshrplib=true, libperl=libperl514.a
>    gnulibc_version=''
>  Dynamic Linking:
>    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
>    cccdlflags=' ', lddlflags='-mdll -s -L"D:\perl32\perl\lib\CORE"
> -L"D:\perl32\c\lib"'
>
>
> Characteristics of this binary (from libperl):
>  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
>                        PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
>                        PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC
>                        USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
>                        USE_SITECUSTOMIZE
>  Built under MSWin32
>  Compiled at Nov 22 2011 18:32:55
>  %ENV:
>    PERL_JSON_BACKEND="JSON::XS"
>    PERL_YAML_BACKEND="YAML"
>  @INC:
>    D:/perl32/perl/site/lib
>    D:/perl32/perl/vendor/lib
>    D:/perl32/perl/lib
>

Portable config information

[Chris Marshall]

I would like to make some module configuration files work with strawberry
perl portable.  Currently, the paths saved in config files are absolute
which means if SPP is moved to another location, things break.

I see that Portable provides something like this.  Is there a standard way
to do the same for other configuration files and/or other modules?  BTW,
the specific files of interest at the moment are Prima::Config and
PDL::Config.

Thanks much,
Chris

Re: Strawberry Perl MSI installer

[Chris Marshall]

Not familiar with MSI details but I hope any changes
won't be a problem for SPP which is useful because
it *doesn't* require special permissions---just enough
to create the folder...

--Chris



On Thu, May 15, 2014 at 1:25 PM, Jan Dubois  wrote:

> On Thu, May 15, 2014 at 8:35 AM, kmx  wrote:
> > it says that PATH contains directories (c:\strawberry\c\bin
> > c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by
> > too wide group of users (built-in Users or even Authenticated Users).
> [...]
> > I feel that our MSI should probably set some filesystem ACL on
> C:\strawberry
> > (which is supported by WiX Toolset we use for MSI creation) but I am not
> > sure what it should be (e.g. Administrators+SYSTEM/FullControl,
> > Users/Read+Execute ?). Any ideas or preferably experiences with building
> MSI
> > are welcome.
>
> The problem is that if you set a more restrictive ACL, then you will
> always need to run from an elevated shell to install additional
> modules from CPAN.  So you have to make a choice between convenience
> and security. My personal opinion: setting a restrictive ACL makes
> sense on a server, but not on a user's desktop.
>
> Cheers,
> -Jan
>

Re: Strawberry Perl 5.22.1.1 released

[Chris Marshall]

Filesys::DfPortable does install out of the box
with the cpan shell (at least for the SPP + PDL version I tried).

--Chris

On 12/18/2015 12:37, John Maag via win32-vanilla wrote:

How does one request a module to be added to Stawberry perl?
 I would like to request Filesys::DfPortable be added

Respectfully,


John Maag




*From:* kmx 
*To:* Win32 Perl mailing list 
*Sent:* Friday, December 18, 2015 4:56 AM
*Subject:* Strawberry Perl 5.22.1.1 released

Strawberry Perl 5.22.1.1 is available at http://strawberryperl.com 



More details in Release Notes:
http://strawberryperl.com/release-notes/5.22.1.1-32bit.html
http://strawberryperl.com/release-notes/5.22.1.1-64bit.html

I would also like to thank our sponsor Enlightened Perl Organisation 
 for resources provided to our project.


--
kmx

Re: Help with libwinprthread-1.dll

[Chris Marshall]

I can't find pthread_setname_np in any of the pthread*.h
files in my Strawberry Perl Portable v52211 which suggests
that it is not supported by the included pthread support.

It is possible that there might be an updated mingw with
that function included.  Another possibility is you could
port the usages of pthread_(set|get)_np to some other
implementation.

--Chris

On 6/21/2016 04:14, RAPPAZ Francois wrote:

Hi there

I'm trying to compile Cairo for perl (strawberry 5.24) on windows 7. I have 
download the package Cairo using msys64.

 From the CPAN/Build Cairo folder I have created the makefile with

perl Makefile.pl INC="-IC:/strawberry/c/include/freetype2 -IC:/msys64/mingw32/include/cairo 
-IC:/msys64/mingw32/include -I. -I./build" LIBS="-Lc:/msys64/mingw32/lib" verbose

In the C:\msys64\mingw32\lib folder I have copied *.dll.a on *.a files to 
prevent undefined reference errors when running dmake, following someone's 
(Rob) suggestion on the mingw-users list.

dmake executes without error.

dmake test

fails with a msgbox "The procedure entry point pthread_setname_np could not be 
located in the dynamic link library libwinprthread-1.dll"
and in the console:
t/00-loading.t 
#   Failed test at t/00-loading.t line 15.
t/00-loading.t  1/18 Bareword "Cairo::LIB_VERSION" not allowed while "strict 
subs" in use at t/00-loading.t line 18.
Bareword "Cairo::lib_version" not allowed while "strict subs" in use at 
t/00-loading.t line 22.
Bareword "Cairo::lib_version_string" not allowed while "strict subs" in use at 
t/00-loading.t line 23.
Bareword "Cairo::version" not allowed while "strict subs" in use at 
t/00-loading.t line 32.
Bareword "Cairo::version_string" not allowed while "strict subs" in use at 
t/00-loading.t line 33.
Execution of t/00-loading.t aborted due to compilation errors.
t/00-loading.t  Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 17/18 subtests etc...

Is it that my libwinpthread-1.dll in my c:/strawberry/perl/bin is not the 
compatible with the one in c:/msys64/mingw32/bin/ (there size differs 51 KB / 
65 KB) ?

Thanks for any help

François

Perl -V says
Summary of my perl5 (revision 5 version 24 subversion 0) configuration:

   Platform:

 osname=MSWin32, osvers=6.3, archname=MSWin32-x86-multi-thread-64int
 uname='Win32 strawberry-perl 5.24.0.1 #1 Tue May 10 17:10:11 2016 i386'
 config_args='undef'
 hint=recommended, useposix=true, d_sigaction=undef
 useithreads=define, usemultiplicity=define
 use64bitint=define, use64bitall=undef, uselongdouble=undef
 usemymalloc=n, bincompat5005=undef
   Compiler:
 cc='gcc', ccflags =' -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS 
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-aliasing 
-mms-bitfields',
 optimize='-s -O2',
 cppflags='-DWIN32'
 ccversion='', gccversion='4.9.2', gccosandvers=''
 intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678, 
doublekind=3
 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12, 
longdblkind=3
 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long 
long', lseeksize=8
 alignbytes=8, prototype=define
   Linker and Libraries:
 ld='g++', ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
 libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\i686-w64-mingw32\lib 
C:\STRAWB~1\c\lib\gcc\i686-w64-mingw32\4.9.2
 libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
 libc=, so=dll, useshrplib=true, libperl=libperl524.a
 gnulibc_version=''
   Dynamic Linking:
 dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' '
 cccdlflags=' ', lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" 
-L"C:\STRAWB~1\c\lib"'


Characteristics of this binary (from libperl):
   Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
 PERLIO_LAYERS PERL_COPY_ON_WRITE
 PERL_DONT_CREATE_GVSV
 PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
 PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
 PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_INT
 USE_ITHREADS USE_LARGE_FILES USE_LOCALE
 USE_LOCALE_COLLATE USE_LOCALE_CTYPE
 USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO
 USE_PERL_ATOF
   Built under MSWin32
   Compiled at May 10 2016 17:20:50
   %ENV:
 PERL5LIB="U:\docs\perl\lib"
 PERL_CPANM_HOME="C:\Users\rappazf\AppData\Local\Perl\.cpanm"
 PERL_JSON_BACKEND="JSON::XS"
 PERL_YAML_BACKEND="YAML"
   @INC:
 U:\docs\perl\lib
 C:/strawberr

Re: Help with libwinprthread-1.dll

[Chris Marshall]

It appears that this routine was added to mingw-w64 git
last year.  I don't know if it is in an official release yet...

https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d95c795b44b76e1b60dfc119fd93cfd0cb35816/

On 6/21/2016 06:51, Chris Marshall wrote:

I can't find pthread_setname_np in any of the pthread*.h
files in my Strawberry Perl Portable v52211 which suggests
that it is not supported by the included pthread support.

It is possible that there might be an updated mingw with
that function included.  Another possibility is you could
port the usages of pthread_(set|get)_np to some other
implementation.

--Chris

On 6/21/2016 04:14, RAPPAZ Francois wrote:

Hi there

I'm trying to compile Cairo for perl (strawberry 5.24) on windows 7. 
I have download the package Cairo using msys64.


 From the CPAN/Build Cairo folder I have created the makefile with

perl Makefile.pl INC="-IC:/strawberry/c/include/freetype2 
-IC:/msys64/mingw32/include/cairo -IC:/msys64/mingw32/include -I. 
-I./build" LIBS="-Lc:/msys64/mingw32/lib" verbose


In the C:\msys64\mingw32\lib folder I have copied *.dll.a on *.a 
files to prevent undefined reference errors when running dmake, 
following someone's (Rob) suggestion on the mingw-users list.


dmake executes without error.

dmake test

fails with a msgbox "The procedure entry point pthread_setname_np 
could not be located in the dynamic link library libwinprthread-1.dll"

and in the console:
t/00-loading.t 

powershell compatible SPP

[Chris Marshall]

Following a conversation with Chas Owens at
YAPC::NA 2017 in Alexandria, we're working
on an implemention of SPP using Windows PowerShell
rather than command.com and .bat files.

Is there anyone else interested in helping
with the project?

--Chris

Re: powershell compatible SPP

[Chris Marshall]

On 6/30/2017 23:54, sisyph...@optusnet.com.au wrote:

-Original Message- From: Chris Marshall
Sent: Saturday, July 01, 2017 5:16 AM
To: win32-vanilla@perl.org
Subject: powershell compatible SPP

Hi Chris,

Following a conversation with Chas Owens at YAPC::NA 2017 in 
Alexandria, we're working on an implemention of SPP using Windows 
PowerShell rather than command.com and .bat files.


On a Windows 10 laptop, I opened a powershell (for the first time in 
my life) and added the location of SPP's gcc and perl  bin folders to 
the path:


PS C:\p> 
$Env:Path="$Env:Path;C:\_64\strawberry5.24.0-ld\c\bin;C:\_64\strawberry5.24.0-ld\perl\bin"


(I'm not proposing that as the solution - I would think you'd want to 
provide an alternative to portableshell.bat that does that for the user.)


Yes, something like portableshell.ps1

But does that provide the functionality that's required ? ... or are 
there some issues regarding the functionality thus obtained ?


The main one is without command.com, all the .bat files for running
perl scripts as programs (think pdl2 or perldl) won't run. I was
thinking to replace the batch files with PowerShell functions (or
cmdlets as they call them).

It seemed fine to me - whereas running SPP's portableshell.bat from 
inside an already existing powershell seemed to bugger up the shell's 
behavioural characteristics.




Can't run .bat files wihout a command.com.  I'm hoping for
a next generation portable shell dot bat.

Cheers,
Chris

Re: powershell compatible SPP

[Chris Marshall]

On 7/3/2017 00:36, sisyph...@optusnet.com.au wrote:



-Original Message- From: Chris Marshall
Sent: Sunday, July 02, 2017 1:32 AM
To: sisyph...@optusnet.com.au ; win32-vanilla@perl.org
Subject: Re: powershell compatible SPP

But does that provide the functionality that's required ? ... or are 
there some issues regarding the functionality thus obtained ?


The main one is without command.com, all the .bat files for running 
perl scripts as programs (think pdl2 or perldl) won't run.


They run ok for me in the powershell - in so far as they start up fine 
and I can run simple scripts on them. (Or do people want to be able to 
run cmdlets in the pdl2 shell ?)




Now, disable cmd.exe on the windows system
and run the test again.

The idea is an SPP that uses PowerShell to
function and can operate on a system without
cmd.exe, command.com, or batch files.

One thing I did notice is that the history (up/down arrow) keys don't 
work in the perldl shell that's run in powershell, though those keys 
work when the perldl shell is run in the cmd.exe shell.

When I switched to using pdl2, the history keys then became functional.

Anyway  I think your main aim at this point was to gauge the level 
of interest in your proposed project, and although I'm not prepared to 
commit to the project, I do find it a bit interesting and would like 
to stay up to date with developments.


Are there more detailed reports (that I can access) of the actual 
problems being experienced ?


The problem is SPP doesn't run without
cmd.exe and batch file support on a PC.

The goal is to be able to use a native
windows perl (SPP) when only PowerShell
is available.  ATM, cygwin perl is an option
for these conditions but the emulation of
POSIX makes for a bit of a performance hit.

Cheers,
Chris