| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
Using the attached patch to the blead source (as of a few hours ago), I can
build perl with the following OS/compiler/make combos.
On 32-bit XP:
MSVC++ 7.0 / dmake (uses win32/makefile.mk)
MSVC++ 7.0 / nmake (uses win32/Makefile)
Borland C++ 5.5.1 / dmake
mingw.org's gcc-4.3.0 / dmake
mingw.org's gcc-3.4.5 / dmake
mingw-w64.sf's 32-bit gcc-4.4.3 / dmake
(There's a bug with that last compiler on XP.
The perl it builds on XP hangs on XP, but runs ok if copied across to Vista.
I think this is unrelated to the patches - probably even unrelated to perl.
Without these patches perl will not even build using that last compiler.)
On 64-bit Vista:
32-bit MSVC++ 7.0 / nmake (uses win32/Makefile)
32-bit MSVC++ 7.0 / dmake (uses win32/makfile.mk)
32-bit Borland C++ 5.5.1 / dmake
mingw.org's 32-bit gcc-4.4.0 / dmake
mingw.org's 32-bit gcc-3.4.5 / dmake
mingw-w64.sf's 32-bit gcc-4.4.3 / dmake
mingw-w64.sf's 64-bit gcc-4.4.3 / dmake
mingw-w64.sf's 64-bit x86_64-w64-mingw32-gcc-4.4.3 / dmake
64-bit MicrosoftPlatform SDK for Windows Server 2003 R2 / dmake (uses
win32/makefile.mk)
64-bit MicrosoftPlatform SDK for Windows Server 2003 R2 / nmake (uses
win32/Makefile)
Not all of those builds pass all tests - but where the removal of the
patches still permits perl to build, the same tests still fail. That is,
*nothing* is lost by including these patches - but there are significant
gains.
Each of the above builds was done according to the normal win32
configuration parameters - ie multi-threaded, non debug. No unusual config
settings were applied. (I did build one debug perl on Vista using
mingw-w64.sf's 32-bit gcc-4.4.3 and it built fine.)
Please feel free to apply these patches (with or without modification) -
and, yes, you're more than welcome to blame me if they cause any breakages
;-)
Of course, some of those compilers (Borland, Microsoft, and the compilers
from mingw.org) already build perl *without* having to apply any patches.
It's just the other compilers that need the patches. The purpose of testing
with Borland, Microsoft, and the mingw.org compilers is just to check that
these patches don't break them.
As a final check, I've done a build on my aging linux (mandrake-9.1) box,
gcc-3.2.2. I built with '-des -Duselongdouble -Duse64bitint -Dusedevel'. No
problem with that, either.
If there's additional testing requirements please let me know, and I'll try
to oblige.
I believe the patch applied successfully for me - see below my sig for the
output.
Cheers,
Rob
Rob@desktop2 ~/GIT/blead
$ patch -p0 <blead_diff.diff
patching file dist/threads/threads.xs
patching file handy.h
patching file cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm
patching file op.c
Hunk #1 succeeded at 5774 (offset 47 lines).
patching file pp_pack.c
patching file util.c
Hunk #1 succeeded at 5366 (offset -28 lines).
patching file win32/makefile.mk
patching file win32/perlhost.h
patching file win32/win32.c
patching file win32/win32.h
patching file README.win32
patching file XSUB.h
|
| |
|
|
|
|
|
|
| |
Perl_deprecate was not part of the public API, and did not have a deprecate()
shortcut macro defined without -DPERL_CORE. Neither codesearch.google.com nor
CPAN::Unpack show any users outside the core.
|
| |
|
|
|
|
|
|
| |
perl.c has the last mentions of PERL_MEM_LOG_ENV*. drop them too.
(rgs: plus some in handy.h's comments too)
|
|
|
|
|
|
|
| |
Most users who want PERL_MEM_LOG want the default implementation,
give it to them. Users providing their own implementation can
obtain current behavior by adding -DPERL_MEM_LOG_NOIMPL.
Frankly, the average user probably wants _ENV by default too.
|
| |
|
|
|
|
|
|
|
|
| |
Other OS parts will follow
From: Steve Peters <steve@fisharerojo.org>
Date: Wed, 25 Mar 2009 10:54:51 -0500
Message-ID: <fd7a59d30903250854q53311f48o6744df7cbfa1d03d@mail.gmail.com>
|
|
|
|
| |
use it where possible.
|
|
|
|
|
|
| |
From: karl williamson <public@khwilliamson.com>
Date: Tue, 16 Dec 2008 16:00:34 -0700
Message-ID: <49483312.80804@khwilliamson.com>
|
|
|
|
|
| |
by the compiler. So further improve the STR_WITH_LEN() macro.
p4raw-id: //depot/perl@34712
|
|
|
|
|
|
| |
This is mostly to silence gcc's warning, "format not a string
literal and no format arguments".
p4raw-id: //depot/perl@34694
|
|
|
|
|
|
| |
Can't easily do gv.h, as GvGP() (at least) needs to split into two
macros - one const for reading, one non-const for writing.
p4raw-id: //depot/perl@34679
|
|
|
| |
p4raw-id: //depot/perl@34654
|
|
|
| |
p4raw-id: //depot/perl@34647
|
|
|
| |
p4raw-id: //depot/perl@34619
|
|
|
| |
p4raw-id: //depot/perl@34612
|
|
|
| |
p4raw-id: //depot/perl@34608
|
|
|
|
|
|
|
|
|
|
| |
away const, returning a void *. Add MUTABLE_SV(sv) which uses this, and
replace all (SV *) casts either with MUTABLE_SV(sv), or (const SV *).
This probably still needs some work - assigning to SvPVX() and SvRV()
is now likely to generate a casting error. The core doesn't do this.
But as-is it's finding bugs that can be fixed.
p4raw-id: //depot/perl@34605
|
|
|
|
|
|
|
|
|
|
| |
so modules like Digest::MD5, that are including perl.h from
within an 'extern "C"' block, will actually see them when
building with a C++ compiler.
Also make sure that Perl_mem_log_(?:new|del)_sv are only seen
by sv.c.
p4raw-id: //depot/perl@34598
|
|
|
| |
p4raw-id: //depot/perl@34585
|
|
|
|
|
| |
Renewc() will return the correct type under PERL_MEM_LOG.
p4raw-id: //depot/perl@34577
|
|
|
| |
p4raw-id: //depot/perl@34574
|
|
|
|
|
| |
Message-ID: <20081022013731.23b5a2e5@r2d2>
p4raw-id: //depot/perl@34568
|
|
|
|
|
| |
Message-ID: <20081022013721.374a490c@r2d2>
p4raw-id: //depot/perl@34567
|
|
|
|
|
| |
Add missing config vars
p4raw-id: //depot/perl@34456
|
|
|
| |
p4raw-id: //depot/perl@34363
|
|
|
| |
p4raw-id: //depot/perl@34107
|
|
|
| |
p4raw-id: //depot/perl@34105
|
|
|
|
|
|
|
| |
places as Perl's malloced_size(), except that we need to be careful of
any PERL_TRACK_MEMPOOL manipulations in force. Wrap both as
Perl_safesysmalloc_size(), to give a consistent name and interface.
p4raw-id: //depot/perl@33379
|
|
|
| |
p4raw-id: //depot/perl@33045
|
|
|
|
|
| |
sv_2mortal(newSVpvs(...)) constructions to use it.
p4raw-id: //depot/perl@32819
|
|
|
| |
p4raw-id: //depot/perl@32793
|
|
|
|
|
|
|
| |
when PERL_CORE is defined. (Which, "obviously", is only in code
within the perl source tree, which we control). Nullop remains, and
would be moderately invasive to remove.
p4raw-id: //depot/perl@32707
|
|
|
| |
p4raw-id: //depot/perl@32237
|
|
|
|
|
|
| |
of change 10855. (to the implementation added in change 18)
Nothing that a decent compiler optimiser would have missed.
p4raw-id: //depot/perl@32041
|
|
|
|
|
|
|
|
| |
manipulations to convert negative lengths to positive length + UTF-8
flag. hv_delete(), hv_exists(), hv_fetch(), hv_store() and
hv_store_flags() all become mathoms. The macros hv_fetchs() and
hv_stores() call hv_common() directly.
p4raw-id: //depot/perl@31931
|
|
|
| |
p4raw-id: //depot/perl@31112
|
|
|
|
|
| |
Message-Id: <200703271207.l2RC7qOC443040@kosh.hut.fi>
p4raw-id: //depot/perl@30774
|
|
|
|
|
| |
and provide memNEs() too.
p4raw-id: //depot/perl@30726
|
|
|
| |
p4raw-id: //depot/perl@29467
|
|
|
|
|
|
| |
From: "Steve Peters" <steve.peters@gmail.com>
Message-ID: <fd7a59d30611042340p5543442ctad306aeb748b6bfe@mail.gmail.com>
p4raw-id: //depot/perl@29238
|
|
|
|
|
| |
Plus forced Glossary entry. That is a TODO for automation
p4raw-id: //depot/perl@29213
|
|
|
|
|
|
|
| |
of data type" with New*()
Message-ID: <44C9A7FC.1060801@iki.fi>
p4raw-id: //depot/perl@28634
|
|
|
| |
p4raw-id: //depot/perl@28301
|
|
|
| |
p4raw-id: //depot/perl@28286
|
|
|
| |
p4raw-id: //depot/perl@28284
|
|
|
|
|
| |
Message-ID: <20060522133933.65ea93ce@r2d2>
p4raw-id: //depot/perl@28273
|
|
|
| |
p4raw-id: //depot/perl@28265
|
|
|
|
|
| |
Message-ID: <20060424232038.7550f9b6@r2d2>
p4raw-id: //depot/perl@27962
|