Re: libthai to strawberry release

[sisyphus]

Hi Dmitry,
Sorry for the late reply - I've only just now realized this message was
sent to the mailing list.
Strawberry Perl is no longer being maintained by kmx, and I don't even know
if anyone has replaced him.
There's still no sign of 5.34.0 and 5.34.1 releases.

I suspect there aren't too many that are subscribed to this mailing list.
I think the best way to attract the attention of anyone interested in
managing releases of Strawberry Perl is to raise an issue at:
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues

Cheers,
Rob

On Sat, Apr 9, 2022 at 9:22 PM Dmitry Karasik  wrote:

> Dear all and kmx,
>
> Would it be possible to add libthai (and probably its dependency
> libdatrie) to
> the next binary dist of strawberry?  This would be needed for proper word
> breaking of thai text. The thai writing has a rather peculiar feature that
> it
> doesn't have spaces between words, and one must bring a small thai
> dictionary
> to make proper text wrapping.
>
> --
> Sincerely,
> Dmitry Karasik
>
>

Re: Windows Script Host support

[sisyphus]

Hi Luigi,
As best I can tell, recent versions of ActivePerl (AP) are
essentially unusable garbage.
You can probably run basic scripts with it, but I found recent AP to be
very limited in capability and also unextendable - which, in the context of
what one expects from perl, means that it is rubbish.

I know that wasn't always the case, and if you have a build of AP that
supports your WSH needs, then I would recommend sticking with it.
I don't think Strawberry Perl ever has or ever will provide that support.

Cheers,
Rob

On Sat, Jun 13, 2020 at 9:30 PM Luigi Iotti  wrote:

> Hi Olivier,
>
>
>
> Yes, ActivePerl still has it, and indeed I use it today. To be precise,
> 5.26 still has it, while I remember I tried a 5.28 build, and it did lack.
>
> I need it primary for Vandyke’ SecureCrt scripting, which makes use of the
> same ActiveX scripting engines WSH uses. So, they tell that if cscript
> //E:PerlScript works, then it should work with SecureCRT. And indeed I
> always found this was the case.
>
>
>
> Just to know, somebody out there on the net instructed how to “steal” the
> feature (a dll, which has to be registered with regsrv32) from AP and use
> it with Strawberry, but I hoped there was some native support. AP can be
> freely downloaded but I don’t know if thir license permits something like
> this (and I bet it is no) and if this is a reliable solution.
>
>
>
> Thank you, regards
>
> Luigi
>
>
>
> *Da:* Olivier Mengué 
> *Inviato:* venerdì 12 giugno 2020 16:24
> *A:* Luigi Iotti 
> *Cc:* Win32 Perl mailing list 
> *Oggetto:* Re: Windows Script Host support
>
>
>
> Hi Luigi,
>
>
>
> I remember that 20 years ago ActivePerl (from ActiveState) had this.
> https://www.activestate.com/products/perl/
>
> I don't think that StrawberryPerl ever had it.
>
>
>
> But nowadays WSH is just legacy. It still works, but Microsoft has stopped
> making it evolve, favoring PowerShell.
>
>
>
> I have quite played with WSH in the past (but using, JavaScript) and often
> suffered from its limitations.
>
> Do you have a motivation for wanting to use Perl from CScript.exe instead
> of perl.exe?
>
>
>
> Olivier.
>
>
>
> Le ven. 12 juin 2020 à 10:21, Luigi Iotti  a écrit :
>
> Hi all,
>
> somebody know if Strawberry Perl supports Windows Script Host (WSH), aka
> ActiveX scripting host (maybe there is a difference between the two
> terms)?
> I mean, if you may run for example cscript //E:PerlScript myscript.pl,
> maybe
> changing PerlScript with some other string.
> This would permit to use Perl as a scripting engine in applications which
> make use of WSH scripting engines.
>
> Thanks, regards
> Luigi
>
>

Re: Setting gmake command arguments in the Strawberry perl CPAN shell

[sisyphus]

Hi Luigi,
Glad you managed to work out a solution.

It seems to me that you've struck a rather strange issue that the
Strawberry Perl developers might be able to deal with - or at least should
be made aware of.

If you would like to have it followed up, I think the best thing would be
to create a New Issue at
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues

Cheers,
Rob






On Sat, Jun 6, 2020 at 12:52 AM Luigi Iotti  wrote:

> Hi sisyphus,
>
>
>
> Thank you for your answer. You pointed me in the right direction.
>
> Setting tet the SHELL env var does not work: it seems that, at least in my
> case, it does not go through all the way from cpan to make.
>
> But instead, it worked just reducing my PATH to just
> C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin
> , before starting cpan.bat.
>
> Thank you very much.
>
>
>
> As a sidenote: I don’t have any sh.exe, or similar, in C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin . There is only jcmd.exe, which
> can resemble a shell. But I think that make’ find_and_set_shell should set
> the shell to C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/_something_.exe, not just the
> folder C:/Program Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin.
>
>
>
> Regards, Luigi
>
>
>
>
>
> *Da:* sisyphus 
> *Inviato:* mercoledì 3 giugno 2020 23:48
> *A:* Luigi Iotti 
> *Cc:* win32-vanilla@perl.org
> *Oggetto:* Re: Setting gmake command arguments in the Strawberry perl
> CPAN shell
>
>
>
> Hi,
>
> I think this happens because gmake finds a file named sh.exe in the PATH -
> in your case it's in "C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/".
>
>
>
> In the perl source, the GNUmakefile in the win32 directory avoids this
> problem by specifying:
>
>
>
> SHELL := cmd.exe
>
>
>
> Is that just a way of setting the SHELL environment variable from inside
> the makefile ?
>
> Does it help if you set the SHELL environment variable to "cmd.exe" before
> starting the build of Alien::wxWidgets :
>
>
>
> set SHELL=cmd.exe
>
>
>
> Cheers,
>
> Rob
>
>
>
> On Wed, Jun 3, 2020 at 11:57 PM Luigi Iotti  wrote:
>
> Hi all
>
> I'm new to Strawberry perl. I just installed 5.30.2.1 on a Win10 pc.
>
> Long story short: in the CPAN shell, how may I add some arguments to gmake
> command line?
> I tried o conf make_arg, make_install_arg, makepl_arg, mbuildpl_arg but
> they
> seem not to work, at least in my case.
>
> Long story long:
>
> I'm trying to build Alien::wxWidgets as it is a requirement for wx. But the
> build fails with:
> ...
> if not exist gcc_mswudll mkdir gcc_mswudll
> process_begin: CreateProcess(NULL, C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/ -c "if not exist gcc_mswudll
> mkdir gcc_mswudll", ...) failed.
> make (e=2): Impossibile trovare il file specificato. #(this means unable to
> find the specified file, in Italian)
> gmake: [makefile.gcc:5089: gcc_mswudll] Error 2 (ignored)
> if not exist ..\..\lib\gcc_dll mkdir ..\..\lib\gcc_dll
> process_begin: CreateProcess(NULL, C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/ -c "if not exist
> ..\..\lib\gcc_dll mkdir ..\..\lib\gcc_dll", ...) failed.
> make (e=2): Impossibile trovare il file specificato. #(this means unable to
> find the specified file, in Italian)
> gmake: *** [makefile.gcc:5639: ..\..\lib\gcc_dll] Error 2
> system: gmake -f makefile.gcc all  UNICODE=1 MSLU=0 BUILD=release SHARED=1
> DEBUG_INFO=default DEBUG_FLAG=1 LDFLAGS=" -m64" CPPFLAGS="-m64": 512 at
> inc/My/Build/Win32.pm line 284.
>
> I found that " C:/Program Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/" is
> the first component of my PATH, and it seems to come from gmake's
> find_and_set_shell.
> If I run the gmake command alone, with -d, it calls find_and_set_shell
> twice. The first time it finds a gnu shell I have somewhere in my PATH, the
> second time it finds the first directory in PATH, not an executable:
>
> >gmake -f makefile.gcc all  UNICODE=1 MSLU=0 BUILD=release SHARED=1
> DEBUG_INFO=default DEBUG_FLAG=1 LDFLAGS=" -m64" CPPFLAGS="-m64" -d
> GNU Make 4.2.1
> Built for x86_64-w64-mingw32
> Copyright (C) 1988-2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> find_and_set_shell() path search set default

Re: Setting gmake command arguments in the Strawberry perl CPAN shell

[sisyphus]

Hi,
I think this happens because gmake finds a file named sh.exe in the PATH -
in your case it's in "C:/Program
Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/".

In the perl source, the GNUmakefile in the win32 directory avoids this
problem by specifying:

SHELL := cmd.exe

Is that just a way of setting the SHELL environment variable from inside
the makefile ?
Does it help if you set the SHELL environment variable to "cmd.exe" before
starting the build of Alien::wxWidgets :

set SHELL=cmd.exe

Cheers,
Rob

On Wed, Jun 3, 2020 at 11:57 PM Luigi Iotti  wrote:

> Hi all
>
> I'm new to Strawberry perl. I just installed 5.30.2.1 on a Win10 pc.
>
> Long story short: in the CPAN shell, how may I add some arguments to gmake
> command line?
> I tried o conf make_arg, make_install_arg, makepl_arg, mbuildpl_arg but
> they
> seem not to work, at least in my case.
>
> Long story long:
>
> I'm trying to build Alien::wxWidgets as it is a requirement for wx. But the
> build fails with:
> ...
> if not exist gcc_mswudll mkdir gcc_mswudll
> process_begin: CreateProcess(NULL, C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/ -c "if not exist gcc_mswudll
> mkdir gcc_mswudll", ...) failed.
> make (e=2): Impossibile trovare il file specificato. #(this means unable to
> find the specified file, in Italian)
> gmake: [makefile.gcc:5089: gcc_mswudll] Error 2 (ignored)
> if not exist ..\..\lib\gcc_dll mkdir ..\..\lib\gcc_dll
> process_begin: CreateProcess(NULL, C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/ -c "if not exist
> ..\..\lib\gcc_dll mkdir ..\..\lib\gcc_dll", ...) failed.
> make (e=2): Impossibile trovare il file specificato. #(this means unable to
> find the specified file, in Italian)
> gmake: *** [makefile.gcc:5639: ..\..\lib\gcc_dll] Error 2
> system: gmake -f makefile.gcc all  UNICODE=1 MSLU=0 BUILD=release SHARED=1
> DEBUG_INFO=default DEBUG_FLAG=1 LDFLAGS=" -m64" CPPFLAGS="-m64": 512 at
> inc/My/Build/Win32.pm line 284.
>
> I found that " C:/Program Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/" is
> the first component of my PATH, and it seems to come from gmake's
> find_and_set_shell.
> If I run the gmake command alone, with -d, it calls find_and_set_shell
> twice. The first time it finds a gnu shell I have somewhere in my PATH, the
> second time it finds the first directory in PATH, not an executable:
>
> >gmake -f makefile.gcc all  UNICODE=1 MSLU=0 BUILD=release SHARED=1
> DEBUG_INFO=default DEBUG_FLAG=1 LDFLAGS=" -m64" CPPFLAGS="-m64" -d
> GNU Make 4.2.1
> Built for x86_64-w64-mingw32
> Copyright (C) 1988-2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> find_and_set_shell() path search set default_shell =
> C:/Utils/GnuWin32/bin/sh.exe
> Reading makefiles...
> Reading makefile 'makefile.gcc'...
> Reading makefile 'config.gcc' (search path) (no ~ expansion)...
> find_and_set_shell() path search set default_shell = C:/Program
> Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin/
> Reading makefile 'gcc_mswudll/*.d' (search path) (don't care) (no ~
> expansion)...
> Updating makefiles...
>
> But if I add SHELL=cmd.exe on the gmake command line, it works. The working
> command line is
> gmake -f makefile.gcc all  UNICODE=1 MSLU=0 BUILD=release SHARED=1
> DEBUG_INFO=default DEBUG_FLAG=1 LDFLAGS=" -m64" CPPFLAGS="-m64"
> SHELL=CMD.exe
>
> Hence my question about setting SHELL= from the CPAN shell.
> Other solutions are welcome.
>
> Thank you, regards
> Luigi
>

Re: libfribidi and libwebp

[sisyphus]

Hi Dmitry,
I recommend creating an issue for this at:
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/

I'm not sure if the people you need to reach are subscribed to this list.

Cheers,
Rob

On Sat, May 2, 2020 at 11:11 PM Dmitry Karasik 
wrote:

> Dear all and especially kmx,
>
> Would you kindly consider adding libfribidi to the next Strawberry version?
> I'm hacking Prima GUI so that it can support advanced unicode stuff,
> right-to-left
> text input, and complex shaping, and fribidi plays a major role there.
>
> Another less important addition is the webp image format, that I added
> support
> some time ago.  Would you possibly consider adding libwebp, libwebpdemux,
> and
> libwebpmux? It's not critical and more of a nice-to-have, but if you do
> that
> I'd be very grateful.
>
> --
> Sincerely,
> Dmitry Karasik
>

Re: why $Config{d_libname_unique} = undef for strawberry perl (DynaLoader.pm) ?

[sisyphus]

On Thu, Sep 12, 2019 at 8:15 PM Ivan Baidakou 
wrote:

> As this is generic issue on Windows-platform,

I'm not so sure that this *is* a generic issue on Windows.
Consider the modules Hash::Util and List::Util, both of which load their
own separate Util.dll.

If it were a generic issue, I would think that loading both of those
modules would create  the same sort of clash as you're seeing with your
modules.
But that doesn't happen:

C:\_32>perl -MHash::Util="all_keys" -MList::Util="uniqnum" -le "print 'ok
1'"
ok 1
C:\_32>perl -MList::Util="uniqnum" -MHash::Util="all_keys" -le "print 'ok
2'"
ok 2

If you can show me how the issue can be reproduced using Hash::Util and
List::Util, then I'll be in agreement that there's a generic Windows issue
interfering here.
Otherwise, I'll remain a little suspicious of the way that you're various
*::XS modules are being loaded.

(On reflection, you might argue that, even if you *are* loading the modules
in an unusual way, it's still a *generic* Windows issue ;-)

> I think it should be fixed in via enabling d_libname_unique. It would be
nice to hear devs, why not enable this option.

My guess is that this would be unfeasible on Windows (because the docs
suggest that it's solely for the benefit of Android) ... but I am only
*guessing* about that.

Cheers,
Rob

Re: perl 5.30.0 and AnyEvent

[sisyphus]

Looking at it a bit more closely, I see that the t/80_ssltest.t tests are
all skipped for me because I don't have Net::SSLeay installed.
When I switch to Strawberry 5.30.0 (which has Net-SSLeay-1.88) I see the
same failure as you.
Also, I think  I misinterpreted the message accompanying the test failure.

Probably the best approach to gaining an understanding of what's going
wrong would be to work your way through "t/80_ssltest.t".

Cheers,
Rob


On Tue, May 28, 2019 at 12:42 PM z...@softvisio.net 
wrote:

> I don't have AV software installed.
> Yes, I know, that I can skip tests, but better, if the are passed.
>
> On 28.05.2019 05:38, sisyphus wrote:
> > Hmmm ... could that be some active anti-virus software interfering with
> > the test ?
> > I would just ignore that failure and install with force by running:
> >
> > cpan -fi AnyEvent
> >
> > (I don't have any such anti-virus software installed here.)
> >
> > Cheers,
> > Rob
> >
> > On Tue, May 28, 2019 at 12:17 PM z...@softvisio.net
> > <mailto:z...@softvisio.net>  > <mailto:z...@softvisio.net>> wrote:
> >
> > Hi,
> >
> > I am trying to intall AnyEvent 7.15.
> >
> > The problem:
> >
> > t/80_ssltest.t . 1/415
> > #   Failed test 'server_error  by
> > the software in your host machine.>'
> > #   at t/80_ssltest.t line 37.
> > # Looks like you failed 1 test of 415.
> > t/80_ssltest.t . Dubious, test returned 1 (wstat 256,
> 0x100)
> > Failed 1/415 subtests
> >
> > Perl -V
> >
> > Summary of my perl5 (revision 5 version 28 subversion 1)
> configuration:
> >
> >   Platform:
> > osname=MSWin32
> > osvers=10.0.17134.407
> > archname=MSWin32-x64-multi-thread
> > uname='Win32 strawberry-perl 5.28.1.1 #1 Sun Dec  2 14:24:00
> > 2018 x64'
> > config_args='undef'
> > hint=recommended
> > useposix=true
> > d_sigaction=undef
> > useithreads=define
> > usemultiplicity=define
> > use64bitint=define
> > use64bitall=undef
> > uselongdouble=undef
> > usemymalloc=n
> > default_inc_excludes_dot=define
> > bincompat5005=undef
> >   Compiler:
> > cc='gcc'
> > ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE
> > -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS
> -DPERL_IMPLICIT_CONTEXT
> > -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing
> > -mms-bitfields'
> > optimize='-s -O2'
> > cppflags='-DWIN32'
> > ccversion=''
> > gccversion='7.1.0'
> > gccosandvers=''
> > intsize=4
> > longsize=4
> > ptrsize=8
> > doublesize=8
> > byteorder=12345678
> > doublekind=3
> > d_longlong=define
> > longlongsize=8
> > d_longdbl=define
> > longdblsize=16
> > 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++.exe'
> > ldflags ='-s -L"D:\devel\perl\perl\lib\CORE"
> > -L"D:\devel\perl\c\lib"'
> > libpth=D:\devel\perl\c\lib D:\devel\perl\c\x86_64-w64-mingw32\lib
> > D:\devel\perl\c\lib\gcc\x86_64-w64-mingw32\7.1.0
> > 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=libperl528.a
> > gnulibc_version=''
> >   Dynamic Linking:
> > dlsrc=dl_win32.xs
> > dlext=xs.dll
> > d_dlsymun=undef
> > ccdlflags=' '
> > cccdlflags=' '
> > lddlflags='-mdll -s -L"D:\devel\perl\perl\lib\CORE"
> > -L"D:\devel\perl\c\lib"'
> >
> >
> > 

Re: perl 5.30.0 and AnyEvent

[sisyphus]

Hmmm ... could that be some active anti-virus software interfering with the
test ?
I would just ignore that failure and install with force by running:

cpan -fi AnyEvent

(I don't have any such anti-virus software installed here.)

Cheers,
Rob

On Tue, May 28, 2019 at 12:17 PM z...@softvisio.net 
wrote:

> Hi,
>
> I am trying to intall AnyEvent 7.15.
>
> The problem:
>
> t/80_ssltest.t . 1/415
> #   Failed test 'server_error  the software in your host machine.>'
> #   at t/80_ssltest.t line 37.
> # Looks like you failed 1 test of 415.
> t/80_ssltest.t . Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/415 subtests
>
> Perl -V
>
> Summary of my perl5 (revision 5 version 28 subversion 1) configuration:
>
>   Platform:
> osname=MSWin32
> osvers=10.0.17134.407
> archname=MSWin32-x64-multi-thread
> uname='Win32 strawberry-perl 5.28.1.1 #1 Sun Dec  2 14:24:00 2018 x64'
> config_args='undef'
> hint=recommended
> useposix=true
> d_sigaction=undef
> useithreads=define
> usemultiplicity=define
> use64bitint=define
> use64bitall=undef
> uselongdouble=undef
> usemymalloc=n
> default_inc_excludes_dot=define
> bincompat5005=undef
>   Compiler:
> cc='gcc'
> ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE
> -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT
> -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing
> -mms-bitfields'
> optimize='-s -O2'
> cppflags='-DWIN32'
> ccversion=''
> gccversion='7.1.0'
> gccosandvers=''
> intsize=4
> longsize=4
> ptrsize=8
> doublesize=8
> byteorder=12345678
> doublekind=3
> d_longlong=define
> longlongsize=8
> d_longdbl=define
> longdblsize=16
> 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++.exe'
> ldflags ='-s -L"D:\devel\perl\perl\lib\CORE" -L"D:\devel\perl\c\lib"'
> libpth=D:\devel\perl\c\lib D:\devel\perl\c\x86_64-w64-mingw32\lib
> D:\devel\perl\c\lib\gcc\x86_64-w64-mingw32\7.1.0
> 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=libperl528.a
> gnulibc_version=''
>   Dynamic Linking:
> dlsrc=dl_win32.xs
> dlext=xs.dll
> d_dlsymun=undef
> ccdlflags=' '
> cccdlflags=' '
> lddlflags='-mdll -s -L"D:\devel\perl\perl\lib\CORE"
> -L"D:\devel\perl\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_IMPLICIT_CONTEXT
> PERL_IMPLICIT_SYS
> PERL_MALLOC_WRAP
> PERL_OP_PARENT
> 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 Dec  2 2018 14:30:03
>   %ENV:
> PERL5LIB="d:/pcore-lib/pcore/lib;"
> PERL_CPANM_HOME="C:\Users\zdm\AppData\Local\Temp\.cpanm"
> PERL_CPANM_OPT="--metacpan --from https://cpan.metacpan.org/;
>   @INC:
> d:/pcore-lib/pcore/lib
> d:/devel/perl/perl/site/lib/MSWin32-x64-multi-thread
> d:/devel/perl/perl/site/lib
> d:/devel/perl/perl/vendor/lib
> d:/devel/perl/perl/lib
>
> On 28.05.2019 02:54, sisyphus wrote:
> > Version 7.15 installed ok for me (with 'cpan -i AnyEvent') on my own
> > build of Windows perl:
> >
> > C:\>perl -v
> > This is perl 5, version 30, subversion 0 (v5.30.0) built for
> > MSWin32-x64-multi-hread
> >
> > What's your 'perl -V' output, and what was the problem ?
> >
> > Cheers,
> > Rob
> >
> > On Tue, May 28, 2019 at 1:02 AM z...@softvisio.net
> > <mailto:z...@softvisio.net>  > <mailto:z...@softvisio.net>> wrote:
> >
> > Does somebody has success with installing AnyEvent?
> > It is successfully installing on linux perl 5.30, but not installing
> > under windows.
> >
>

Strawberry Perl 5.28.0

[sisyphus]

Hi,

Anyone know when Strawberry Perl 5.28.0 will be released ?

Cheers,
Rob

Odd output with 5.16.0, x86-64int architecture

[Sisyphus]

Hi,

Here's the demo (Inline::C) script:

###
use warnings;
use Config;
use Math::MPFR qw(:mpfr);

use Inline C = Config =
   CCFLAGS = -D__USE_MINGW_ANSI_STDIO=1  . $Config{ccflags},
   BUILD_NOISY = 1;

use Inline C = 'EOC';

#include stdio.h
#include stdlib.h
#include math.h

void check(char * in, SV * digits) {
dXSARGS;
long double ld;
char *ptr, *buffer;;

ld = strtold(in, ptr);

buffer = malloc(32 * sizeof(char));
sprintf(buffer, %.*Le, SvUV(digits) - 1, ld);
ST(0) = sv_2mortal(newSVpv(buffer, 0));
free(buffer);
XSRETURN(1);

}

EOC

print check('1e-37', 18), \n;
###

For both the x86 and x64 builds of Strawberry Perl-5.16.0 that script 
correctly outputs:

1.0e-037

But for the x86-64int build of Strawberry Perl-5.16.0 I'm getting:
-0.0e+000

Does anyone see a reason for this anomalous behaviour with the x86-64int 
build ?
I get precisely the same output with an x86-64int perl-5.16.0 that I built 
using mingw.org's gcc-4.5.2.


Here's the 'perl -V' of the problem Strawberry Perl:


Summary of my perl5 (revision 5 version 16 subversion 0) configuration:

 Platform:
   osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread-64int
   uname='Win32 spp-spec-64int 5.16.0.1 #1 Tue May 22 21:03:41 2012 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=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 -fno-strict-aliasing -mms-bitfields',
   optimize='-s -O2',
   cppflags='-DWIN32'
   ccversion='', gccversion='4.6.3', gccosandvers=''
   intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
   d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
   ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long 
long',

lseeksize=8
   alignbytes=8, prototype=define
 Linker and Libraries:
   ld='g++.exe', ldflags 
='-s -LC:\_32\strawberry516_64int\perl\lib\CORE -LC

:\_32\strawberry516_64int\c\lib'
   libpth=C:\_32\strawberry516_64int\c\lib 
C:\_32\strawberry516_64int\c\i686-w6

4-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 -ladva
pi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lver
sion -lodbc32 -lodbccp32 -lcomctl32
   libc=, so=dll, useshrplib=true, libperl=libperl516.a
   gnulibc_version=''
 Dynamic Linking:
   dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
   cccdlflags=' ', 
lddlflags='-mdll -s -LC:\_32\strawberry516_64int\perl\lib\C

ORE -LC:\_32\strawberry516_64int\c\lib'


Characteristics of this binary (from libperl):
 Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
   PERLIO_LAYERS PERL_DONT_CREATE_GVSV
   PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
   PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC
   USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
   USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
   USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
 Built under MSWin32
 Compiled at May 22 2012 21:11:55
 %ENV:
   PERL_JSON_BACKEND=JSON::XS
   PERL_YAML_BACKEND=YAML
 @INC:
   C:/_32/strawberry516_64int/perl/site/lib
   C:/_32/strawberry516_64int/perl/vendor/lib
   C:/_32/strawberry516_64int/perl/lib
   .


Cheers,
Rob

Re: Odd output with 5.16.0, x86-64int architecture

[Sisyphus]

- Original Message - 
From: Sisyphus sisyph...@optusnet.com.au

To: win32-vanilla@perl.org
Sent: Friday, September 07, 2012 1:00 AM
Subject: Odd output with 5.16.0, x86-64int architecture



Hi,

Here's the demo (Inline::C) script:

###
use warnings;
use Config;
use Math::MPFR qw(:mpfr);

use Inline C = Config =
   CCFLAGS = -D__USE_MINGW_ANSI_STDIO=1  . $Config{ccflags},
   BUILD_NOISY = 1;

use Inline C = 'EOC';

#include stdio.h
#include stdlib.h
#include math.h

void check(char * in, SV * digits) {
dXSARGS;
long double ld;
char *ptr, *buffer;;

ld = strtold(in, ptr);

buffer = malloc(32 * sizeof(char));
sprintf(buffer, %.*Le, SvUV(digits) - 1, ld);
ST(0) = sv_2mortal(newSVpv(buffer, 0));
free(buffer);
XSRETURN(1);

}

EOC

print check('1e-37', 18), \n;
###

For both the x86 and x64 builds of Strawberry Perl-5.16.0 that script 
correctly outputs:

1.0e-037

But for the x86-64int build of Strawberry Perl-5.16.0 I'm getting:
-0.0e+000


Duh - it's just that I need to cast SvUV(digits) to an unsigned long:

sprintf(buffer, %.*Le, (unsigned long)SvUV(digits) - 1, ld);

Cheers,
Rob

Re: 32bit strawberry perl with -Duse64bitint

[Sisyphus]

- Original Message - 
From: kmx




Of course *dbm thinks are absolutely unrelated to -Duse64bitint. I have
just taken the changes we do in standard strawberry perl + applied
additional changes related to -Duse64bitint.


Understood.


In
http://svn.ali.as/cpan/trunk/Perl-Dist-Strawberry/share/perl-5.16/diffs_for_info_only/
you can see what changes are standard in strawberry perl. I think you 
can

easily distinguish what has to be patched for -Duse64bitint.


Yes, no problems there.
Thanks.

Cheers,
Rob 

Re: 32bit strawberry perl with -Duse64bitint

[Sisyphus]

- Original Message - 
From: kmx k...@atlas.cz

To: win32-vanilla@perl.org
Sent: Wednesday, May 16, 2012 6:53 PM
Subject: Re: 32bit strawberry perl with -Duse64bitint





One thing I noticed is that $Config{archname} still reports
'MSWin32-x86-multi-thread'.
I think it should probably differentiate itself from -Uuse64bitint
builds, though I'm not sure of the rules in this regard (if there are 
any).

Perhaps something like 'MSWin32-x86-multi-thread-64int' - but if there
are no rules, then I reckon *you* get to choose.



Well, I have changed in config_H.gc:

#define ARCHNAME MSWin32-x86-64int

but it is obviously the wrong place and the wrong string - I should revert
it. It seems that some hacking/patching in win32/makefile.mk can fix this.


Oh, yes ... I think that's right. (I've been searching the source for 
'multi-thread' and wondering why I wasn't getting any useful hits.)


I already see:

.IF $(USE_ITHREADS) == define
ARCHNAME !:= $(ARCHNAME)-thread
.ENDIF

So I guess it's just a matter of adding after that something like:

.IF $(USE_64_BIT_INT) == define
ARCHNAME !:= $(ARCHNAME)-64int
.ENDIF


Looking forward to the arrival of  'MSWin32-x86-multi-thread-64int-ld' 
;-)




you mean -Duselongdouble?


That's right. (It'd be nice - but this is not a serious request for it.)

If one wanted to add the -Duse64bitint capability to the official perl 
sources (say, for 5.18) would one be looking at providing an additional 
config.gc (say, config.gc_int64) and an additional config_H.gcc 
(config_H.gc_int64) ?


That's the way *I* would go about it ... just wondering if you see a better 
way.


Cheers,
Rob 

Re: 32bit strawberry perl with -Duse64bitint

[Sisyphus]

- Original Message - 
From: kmx k...@atlas.cz

To: win32-vanilla@perl.org
Sent: Wednesday, May 16, 2012 7:37 AM
Subject: 32bit strawberry perl with -Duse64bitint



On 28.4.2012 5:13, Sisyphus wrote:

...
kmx, have you already been working on building a 32-bit SP with
-Duse64bitint ?


Now available at http://strawberryperl.com/beta/ (only Portable edition
based on perl-5.16.0-RC1)

Applied patches to config.gc and config_H.gc are here:
http://svn.ali.as/cpan/trunk/Perl-Dist-Strawberry/share/perl-5.16-x86-64int/diffs_for_info_only/


Excellent !!
I'll try this out as soon as I get a chance.

Is the dbm/gdbm/ndbm stuff critical to the build of a -Duse64bitint perl ?
(I'll probably wait until 5.16.0 is released, whereupon I intend to try 
building such a perl myself, using the mingw.org compiler (gcc-4.5.2). It 
doesn't have any of  the dbm/gdbm/ndbm stuff, afaik.)


Cheers,
Rob 

Re: problems with strawberry perl portable and cpan

[Sisyphus]

- Original Message - 
From: René Staffen r.staf...@gmx.de

To: win32-vanilla@perl.org
Sent: Friday, April 27, 2012 1:55 AM
Subject: Re: problems with strawberry perl portable and cpan



Hi,

Please try strawberry perl portable 5.14.2.1 from release page
http://strawberryperl.com/releases.html - portable 5.12.3 is buggy.


Thank you for this information.

Is there a way to upgrade without the need to reinstall all the modules i 
installed so far?


You could install 5.14.2.1 to the same location, and you wouldn't have to 
re-install any pure perl modules that you had previously installed.
But you would still have to re-install any perl extensions (ie modules with 
C/XS code that needs to be compiled) that you had previously installed.


Cheers,
Rob 

Re: problems with strawberry perl portable and cpan

[Sisyphus]

- Original Message - 
From: kmx k...@atlas.cz

To: win32-vanilla@perl.org
Sent: Sunday, April 29, 2012 3:46 AM
Subject: Re: problems with strawberry perl portable and cpan





kmx, have you already been working on building a 32-bit SP with
-Duse64bitint ?


Not yet but we already have some hackery applied on win32/config_H.gc and
win32/config.gc - I expect that couple of more hacking in these two files
can make use64bitint possible.

I can do more on this after I release strawberry 5.16.0  (approx the end 
of

May).


Excellent - I look forward to it.

Cheers,
Rob 

Re: problems with strawberry perl portable and cpan

[Sisyphus]

- Original Message - 
From: kmx



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


It's been a while since I looked at doing this, but I think *I* would still 
find the patching involved in building a 32-bit Windows perl 
with -Duse64bitint both tedious and difficult ... however, that doesn't mean 
that you and/or kmx would also suffer the same :-)


Chris, your Cygwin perl should be suitable for testing the 32-bit 
with -Duse64bitint scenario.


Currently the build engine is under complete reconstruction. How quickly 
do

you need it?


kmx, have you already been working on building a 32-bit SP 
with -Duse64bitint ?


It's something I'd like to see  and something I'd like to be able to 
build from source.
It would also be nice to have -Duselongdouble support (even if just for the 
x64 builds).


If you do have patches that enable any of this, it would be nice (though 
*not* obligatory upon you) if they could be made available for integration 
into the official perl sources.


Cheers,
Rob

Re: gcc for building Perl on WinXP

[Sisyphus]

- Original Message - 
From: kmx



Apart from:
http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip

http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip


We have also prepared other PDL handy stuff - like:
http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gfortran4.4.7-pre_2001.zip

http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_gsl-1.15-bin_2004.zip

http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_fftw-2.1.5-bin_20110506.zip


It is only about decision how fat should strawberry perl be.


Yes - and making those additional drop-in zips available is probably a fair 
compromise.
I don't think I've ever seen anyone other than me raise this matter, so 
demand for this support can't be all that high :-)


I'll grab and install those additional bits and try them out next time I 
build PDL with Strawberry. (I'm sure they're fine - there's absolutely no 
reason to expect otherwise.)



On threaded perls, that TLS capability can be handy for Math::MPFR.


Thanks for this notice, I will try to use --enable-TLS by the next
mpfr-3.1+ rebuild (according ./configure --help it seems not to be
available in 3.0.1).


With 3.1+ TLS should be built in without any need for being requested. If it 
doesn't happen, it means that the compiler has been found to *not* support 
TLS - but both my mingw64.sf 4.7.0 cross-compiler and mingw.org 4.5.2 
compiler do provide the necessary bits. Mingw.org's 3.4.5 compiler 
apparently did not.
So, I'm guessing (and it is only a guess) that the Strawberry compilers will 
provide TLS as well. If it gives you trouble you can, of course, 
still --disable-TLS.
I *think* the 3.1.0 release notes implied that the --enable-TLS option was 
valid for the 3.0* versions of the mpfr library, but I never tried it out 
and I could be wrong.
I wasn't even expecting 3.1.0 to build with TLS support, and was pleasantly 
surprised when it did :-)



I noticed, too, that the mpc library that ships with Strawberry hasn't
been built to accommodate the complex.h types (double _Complex and
long double _Complex).



To enable this should I pass some extra option to mpc configure/make?


No - the problem is a bug in mpc.h. The expectation is that if a there's a 
suitable complex.h available, then the symbol _COMPLEX_H will be defined, 
but this is wrong since many complex.h versions (including mingw) don't 
define that symbol. I hacked my compiler's complex.h to define that symbol, 
and that worked fine - but many would consider that to be the *wrong* hack.


Here's the offending piece of code in mpc.h:

/* Check if complex.h is included */
#if defined (_COMPLEX_H)
# define _MPC_H_HAVE_COMPLEX 1
#endif

I guess you might prefer to change *it* instead of altering your compiler's 
complex.h. The fix on the svn repo has mpc.h check that _Complex_I is 
defined, so changing the first line of the above code to


#if defined(_Complex_I)

should work for you.
In any case, there should be no such issue with the next release of mpc.

Cheers,
Rob 

Re: gcc for building Perl on WinXP

[Sisyphus]

- 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: Looking for Cairo for Windows (to have Chart::Clicker)

[Sisyphus]

- Original Message - 
From: Gabor Szabo



After some research the in place part is unclear to me. I'll further
research it
though if you could tell me where should I put the cairo and gobject 
libraries

and what else I might need, that would be of great help.


You can put them anywhere you like - if you're using pre-compiled binaries I 
think it's preferable to put them in a place that doesn't override any 
existing libraries.

I have them in C:/Gtk+.

You need to install ExtUtils::Depends and ExtUtils::PkgConfig. (I think 
they'll install ok with 'cpan -i...'.)


Then set the PKG_CONFIG_PATH environment variable to the location of the 
folder that contains  the various '.pc' files (such as cairo.pc). For me 
that was C:\Gtk+\lib\pkgconfig.


Make sure the dll files are in your path, then 'cpan -i Cairo'. (I actually 
download the source manually and run 'perl Makefile.PL', etc. ... but I 
think 'cpan -i ...' should be fine.)


Cairo itself doesn't appear to need many of the Gtk+ libraries. For my x86 
builds, it seems that only the cairo, png and zlib libraries are needed. For 
some reason my x64 builds additionally require the fontconfig, expat and 
freetype libraries.


See how you go !!

Cheers,
Rob