Hi,
My own efforts to support building Perl + wxWidgets have resulted in
http://sourceforge.net/projects/perlmingw/files/
It is a build of 4.6.2 with pthreads and includes gfortran and libquadmath.
It seems to build PDL from git without problems. The bundled
Config_MinGWFP ( set PERL5OPT=-MConfig_MinGWFP ) allows use with ActivePerl.
One thing I'm unqualified to test:
fortran io was reported to be very poor in 4.6.1 but a fix is claimed
for 4.6.2 release - so for users of gfortran it would be worth
investigating io performance vs a gcc 4.5.x build. Note that apparently
the io problems with 4.6.1 are so bad it should not take too much to detect.
Building Perl on Win XP 32 bit is now OK.
Libraries built with recent ( 18 months) sezero builds of mingw-w64
should be ABI compatible and not require recompilation.
The compiler toolchain itself is a native build using MSYS. The full
build system and a single 'build everything' script are available.
I'll be producing a pre-built library pack containing my common
dependencies ( zlib, openssl, libpq, libmysql, libgd ) shortly.
Personally I'm not precious about 'ownership' of the 'project' or pretty
much anything else other than that the compilers must; support Win XP
and above, compile Perl, compile wxWidgets/wxPerl. So if anyone fancies
sharing ownership and support ...... :)
Regards
Mark
On 07/11/2011 22:28, kmx wrote:
Yes, "dmake clean" did the trick.
Thanks.
--
kmx
On 7.11.2011 22:32, Chris Marshall wrote:
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<devel.chm...@gmail.com>
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<k...@atlas.cz> 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<devel.chm...@gmail.com> 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_20111101.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<sisyph...@optusnet.com.au>
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
