Re: [OT] Problem building gd-2.0.35 library

2012-12-04 Thread Mark Dootson

Hi

On 04/12/2012 07:53, Sisyphus wrote:

Hi,

Obviously way OT for this list - but I see that Strawberry ships with
gd-2.0.35, so I'm hoping someone here has faced (and solved) the problem
I've struck.


For Citrus I use cmake on Windows, Linux and MacOSX.  My notes for 64 
bit mingw build are:


# - remove -m32 flag in top CMAKEfiles.txt for 64 bit, then :-

cmake -GMinGW Makefiles -DCMAKE_INSTALL_PREFIX=C:\buildprefix 
-DCMAKE_LIBRARY_PATH=C:\buildprefix\lib 
-DCMAKE_INCLUDE_PATH=C:\Projects\buildprefix\include -DENABLE_PNG=1 
-DENABLE_FREETYPE=1 -DENABLE_JPEG=1 -DCMAKE_RELEASE_TYPE=RELEASE ..\



My builds of freetype, jpeg and png are already in the prefix location.

Hope it helps.

Mark





Re: gcc for building Perl on WinXP

2011-11-11 Thread Mark Dootson

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 Marshalldevel.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, kmxk...@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, chmdevel.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_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 

Re: gcc for building Perl on WinXP

2011-11-02 Thread Mark Dootson

It is the 32bit version of mingw-w64.

Source at

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/sezero_4.5_2001/

The native 32 bit compiler is

mingw-w32-bin_i686-mingw_2001_sezero.zip



The bundled compiler toolchains that come with Strawberry Perl are based on

http://mingw-w64.sourceforge.net/

Hope it helps


Mark



On 02/11/2011 17:41, Sergei Steshenko wrote:





- Original Message -

From: Mark Dootsonmark.doot...@znix.com
To: Chris Marshalldevel.chm...@gmail.com
Cc: Karel Mikokarel.m...@hotmail.com; win32-vanilla@perl.org
Sent: Wednesday, November 2, 2011 7:04 PM
Subject: Re: gcc for building Perl on WinXP

Hi,

At mingw-w64 Oskan Sezer (sezero) has updated his release of gcc 4.5.4
including latest patches.


[snip]

I do not see gcc-4.5.4 at gcc.gnu.org . The latest gcc-4.5.X I see is gcc-4.5.3.

Does such a release really exist ?

Thanks,
   Sergei.





gcc for building Perl on WinXP

2011-10-30 Thread Mark Dootson

Hi,

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.


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.


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.


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)


Hope it helps


Mark