Re: gcc for building Perl on WinXP

[email protected] (kmx)
Newsgroups perl.win32.vanilla
Message-ID <[email protected]>
Mark,

As you probably know strawberry perl is using sezero's gcc toolchain 
build since approx April 2010.

We use "nearly exactly" the original sezero's gcc 4.4.x toolchain - 
there are basically 2 things we have changed

1/ sezero's gcc builds ignore <gccroot>/include dir when searching for 
*.h files which is not good as we put a lot of stuff into 
c:\strawberry\c\include - fortunately the fix is just a little change to 
build scripts not to gcc code (more details at 
http://sourceforge.net/tracker/?func=detail&aid=2886331&group_id=202880&atid=983354)

2/ we have one more header: glext/glxext.h

Upgrading strawberry perl to sezero's gcc-4.5.x (which works well with 
latest wxWidget, right?) is feasible as Ozkan has done a really great 
job (carefully selected patches, nicely prepared, easily to rebuild). 
The only thing as regards strawberry perl is that we need to rebuild 
with gcc-4.5.x also all external libraries (20-30 packages). That's the 
point where I am in doubts whether to go 4.4.x >> 4.5.x or directly 
4.4.x >> 4.6.x

The biggest (the only) disadvantage of gcc-4.6.x is that Ozkan have 
currently no plans making gcc-4.6.x build (I have asked him a couple of 
days ago) - so with gcc-4.6.x we loose all comfort we have now with his 
gcc-4.4.x/4.5.x builds

--
kmx


On 2.11.2011 18:04, Mark Dootson wrote:
> Hi,
>
> At mingw-w64 Oskan Sezer (sezero) has updated his release of gcc 4.5.4 
> including latest patches. This solves my wxWidgets (c++) issues ( and 
> general c++ exception problems for many other things I expect).
>
> It should also solve the Windows XP CRT issue which caused strawberry 
> to stick with gcc 4.4.3 for Win32 - I haven't tested on XP yet (Oskan 
> only updated it today) but I've tested the relevant patch for other 
> builds so it should work fine.
>
> It comes with gfortran.
>
> No expectations of Oskan of course, but given Oskan's record of 
> updating his releases and ease of using his source patches + 
> buildscripts yourself if you wish, this looks like a favourite base 
> for a Perl gcc dist.
>
> Mark
>
>
> On 02/11/2011 16:46, Chris Marshall wrote:
>> 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<[email protected]>  
>> 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<gccroot>/include and<gccroot>/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
>>>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.