| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Surround http:// links with L<> and tidying up lists slightly.
|
|
|
|
|
|
|
|
| |
The sources did support to drop win32/fcrypt.c from a Perl distribution
and build without a crypt() implementation to account for the paranoia
around distribution of encryption technology. However sources and binaries
have been released for at least 10 years with all the code in place, so
there is not much point in making it configurable.
|
|
|
|
|
| |
Remove all supporting code for Windows 9x and Windows NT. The
minimum supported version is Windows 2000 now.
|
| |
|
|
|
|
|
| |
Also add a couple of things to win32/makefile.mk which were only previously
applied to win32/Makefile
|
|
|
|
|
|
| |
All Win32::* modules on CPAN now build with standard toolchain
commands; there is no need for "porting" or special build instructions
anymore.
|
|
|
|
|
|
|
| |
There are know issues with that compiler versions, and the necessary
fixes are no longer readily available, so stop claiming this is still
a supported compiler. Just require gcc 3.2.x or later everywhere for
MinGW support.
|
|
|
|
|
|
| |
Remove reference to old compilers and also use the current
name "Windows SDK" instead of the older "Platform SDK" in most
places. There is sill lots of chance for further improvements!
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
| |
p4raw-id: //depot/perl@33335
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@activestate.com>
Message-ID: <0cdf01c84684$f99c3310$ecd49930$@com>
p4raw-id: //depot/perl@32722
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@activestate.com>
Message-ID: <03cd01c82b07$581a1950$084e4bf0$@com>
p4raw-id: //depot/perl@32411
|
|
|
| |
p4raw-id: //depot/perl@31761
|
|
|
|
|
|
|
|
|
| |
Different versions install into different default locations, as
pointed out here:
Subject: Building 5.9.5 with Win2k, MSVC8FREE
Message-Id: <1D149669-931C-4458-B073-789D25623D2D@rectangular.com>
p4raw-id: //depot/perl@31571
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unknown to me win32/win32.h was defining USE_FIXED_OSFHANDLE, which
arranged for a black magic fix to MSVCRT.DLL's _open_osfhandle() to
be used. It seems that this is inappropriate for VC++ versions later
than 6.x, since they don't use that DLL: simply not defining that
symbol makes the io_sock.t failure go away.
(Compare change #29233, which similarly disabled the fix to
MSVCRT.DLL's read() for VC++ versions later than 6.x.)
p4raw-link: @29233 on //depot/perl: 46e77f111828d72136c91f0837803182535da01d
p4raw-id: //depot/perl@31271
|
|
|
| |
p4raw-id: //depot/perl@29409
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add some instructions in README.win32, clarify macro comments and add
missing macros to makefile.mk, and drop the GLOBEXEBUILD macro from
Makefile--the Express Edition of Visual C++ 2005 is free and includes
setargv.obj, so there is no need to support the .NET 2.0 SDK compiler
which didn't include it.
Unfortunately, the build still doesn't work yet--my attempt got as far
as building extensions, but miniperl.exe crashed. Hopefully this can
be sorted out soon.
p4raw-id: //depot/perl@28978
|
|
|
|
|
|
|
|
|
| |
From: "Jan Dubois" <jand@ActiveState.com>
Message-ID: <060201c64e45$e4ca7020$2217a8c0@candy>
Also, back out change #27567.
p4raw-link: @27567 on //depot/perl: 9bf76a6a2fc16ab628a46452e34352d3e3d71674
p4raw-id: //depot/perl@27576
|
|
|
|
|
| |
Message-Id: <E44A2151-DE7F-4C5D-8A4B-DDA0412229C2@mac.com>
p4raw-id: //depot/perl@27567
|
|
|
|
|
| |
Steve Hay.
p4raw-id: //depot/perl@27503
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce new CCTYPE's MSVC70FREE and MSVC70 for the free and the full
versions of MS VC++ 7.x respectively. Perl can now be built with the
free VC++ toolkit simply by running "nmake CCTYPE=MSVC70FREE" with no
hacking of the win32/Makefile required. Update README.win32 with
these changes.
Also add the CCTYPE MSVC to win32/Makefile. This is already supported
in win32/makefile.mk and is useful for avoiding the use of -DELAYLOAD
for MS VC++ 3.x through 5.x. Update README.win32 for this too.
p4raw-id: //depot/perl@25672
|
|
|
|
|
|
|
| |
I give up trying to keep the Platform SDK links up-to-date. They seem
to have changed every time that I look at them, so make the
instructions more general.
p4raw-id: //depot/perl@25513
|
|
|
|
|
| |
(Mention Borland compiler is also free; update libwin32 link)
p4raw-id: //depot/perl@24868
|
|
|
|
|
|
| |
From: "Konovalov, Vadim" <vkonovalov@spb.lucent.com>
Message-ID: <7DD1BE2C50259746ABB8683672D2089E12D462@itotest-1.spb.lucent.com>
p4raw-id: //depot/perl@24719
|
|
|
|
|
|
| |
Use the generic search.cpan.org URL so that the latest version is
always found
p4raw-id: //depot/perl@24321
|
|
|
| |
p4raw-id: //depot/perl@23972
|
|
|
|
|
|
| |
Subject: Patch to README.win32 distributed with 5.8.6 for building under .net / MSVC7 (free)
Message-ID: <41B355EC.9010505@corion.net>
p4raw-id: //depot/perl@23621
|
|
|
| |
p4raw-id: //depot/perl@23227
|
|
|
| |
p4raw-id: //depot/perl@23224
|
|
|
|
|
|
|
|
| |
causing subsequent print/read to hang or misbehave
Patch supplied by Artiom Morozov <artiom@phreaker.net>
in the bug report at http://rt.perl.org/rt3/index.html?q=24269
p4raw-id: //depot/perl@23200
|
|
|
| |
p4raw-id: //depot/perl@23172
|
|
|
|
|
| |
Message-ID: <40BF39B9.3060207@uk.radan.com>
p4raw-id: //depot/perl@22901
|
|
|
|
|
|
| |
Message-Id: <200404222357.40508.abe@ztreet.demon.nl>
Changed download URL references for nmake
p4raw-id: //depot/perl@22735
|
|
|
|
|
| |
Message-ID: <405EFBDE.4090209@uk.radan.com>
p4raw-id: //depot/perl@22556
|
|
|
|
|
| |
Message-ID: <4010038D.4070104@uk.radan.com>
p4raw-id: //depot/perl@22195
|
|
|
|
|
|
|
| |
Message-ID: <3F3B9F14.4040609@uk.radan.com>
(Sarathy okayed the idea.)
p4raw-id: //depot/perl@20702
|
|
|
|
|
|
| |
From: "Brent Dax" <brentdax@cpan.org>
Message-ID: <034e01c28d3e$0fed1680$6501a8c0@deepblue>
p4raw-id: //depot/perl@18161
|
|
|
|
|
| |
Message-ID: <3DB00CB9.70708@alianwebserver.com>
p4raw-id: //depot/perl@18046
|
|
|
| |
p4raw-id: //depot/perl@17671
|
|
|
|
|
| |
Message-Id: <5.1.0.14.2.20020619192631.025848a0@pop.skynet.be>
p4raw-id: //depot/perl@17306
|
|
|
|
|
| |
Message-ID: <20020607113651.GC24159@lupe-christoph.de>
p4raw-id: //depot/perl@17059
|
|
|
| |
p4raw-id: //depot/perl@16997
|
|
|
|
|
| |
allocating half of the retstack!)
p4raw-id: //depot/perl@16181
|
|
|
| |
p4raw-id: //depot/perl@16149
|
|
|
| |
p4raw-id: //depot/perl@16060
|
|
|
| |
p4raw-id: //depot/perl@16050
|