summaryrefslogtreecommitdiff
path: root/README.win32
Commit message (Collapse)AuthorAgeFilesLines
* improve and reword README.win32Daniel Dragan2015-01-131-7/+33
| | | | (cherry picked from commit 8f5839a98a66edafefd2ffd3056e5e3fc64e1d27)
* Remove note of test failures on FAT that were fixed by perl #21442's fixesSteve Hay2014-05-241-4/+0
| | | | | The list of tests fixed doesn't exactly match the list in README.win32, but all tests now pass when building/testing on FAT with the Windows OS on NTFS.
* Document known test failure in www.mingw.org builds of gcc-4.8.1 (at least)Steve Hay2014-05-231-0/+4
| | | | | This came up in perl #121643, but I forgot to add a note of this Known Problem.
* Note that the minimum supported gcc (on Windows) is 3.4.5Steve Hay2014-05-221-2/+2
| | | | | | Earlier versions (from www.mingw.org, at least) will build perl, but have a linker bug that causes various tests to fail due to problems with SDBM_File.dll. See perl #121936 for details.
* bump version to 5.20.0, install 5.20 perldeltaRicardo Signes2014-05-121-1/+1
|
* Add link to MS article about broken _utime() in VC++ 2013Steve Hay2014-01-071-1/+6
|
* Extend Intel C++ compiler support (a48cc4c427) to dmake buildsSteve Hay2013-11-261-5/+5
|
* List another VC++ 2013 test failureSteve Hay2013-11-251-3/+3
| | | | | | | | | | | | | | The first two happened when in BST but don't happen now, back in GMT; but lib/File/Copy.t now fails instead! This is all due to _utime() being broken in VC++ 2013's CRT. Microsoft have acknowledged there is a regression from previous versions of the CRT in a support ticket that I logged with them, and will publish a Knowledge Base article about it in due course. (Users can workaround it by using the Win32::UTCFileTime module on CPAN, which exists to fix other (long-standing) issues with _stat() and _utime(), but also fixes this new breakage too.)
* add Intel C++ Compiler for Win32 supportDaniel Dragan2013-11-201-0/+13
| | | | | | | | | | | | -most fixes involve code detecting Perl on VC, and changing it to ICC is another kind of VC, but ICC's version isn't this "other kind of VC"'s version number, call the partner VC to find out the "VC version number" of ICC not yet done -no Intel C specific optimization flags -long doubles and C99 -ccversion behavior might not be ideal/rethink
* Add support for building with Visual C++ 2013Steve Hay2013-10-221-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two tests (t/io/fs.t and cpan/HTTP-Tiny/t/110_mirror.t) fail on my system, currently in Daylight Saving Time, both due to times written/read by utime()/stat() being off by one hour... Not sure what the issue is yet, but I've reproduced it in this C program: #include <stdio.h> #include <sys/stat.h> #include <sys/utime.h> void main(void) { struct _utimbuf ut; struct _stat st; time_t t; t = 760060800; printf("Setting: %ld\n", t); ut.actime = t; ut.modtime = t; if (_utime("test.c", &ut) == -1) { perror("_utime failed\n"); return; } if (_stat("test.c", &st) != 0) { perror("_stat failed\n"); return; } printf(" atime: %ld\n", st.st_atime); printf(" mtime: %ld\n", st.st_mtime); } which outputs Setting: 760060800 atime: 760057200 mtime: 760057200 with VC++ 2013, instead of Setting: 760060800 atime: 760060800 mtime: 760060800 like Visual C++ 6.0 through 2012 all do.
* Note that the USE_64_BIT_INT build option is not supported with MSVC++ 6.0Steve Hay2013-09-161-1/+4
| | | | | | | Also change the Windows makefiles to disable this option if it is set with this compiler selected. (Use !UNDEF (for nmake) and != (for dmake) to be sure of disabling the option if it is defined on the command-line rather than by editing the makefile.)
* bump version to 5.19.0Ricardo Signes2013-05-181-1/+1
|
* Bump version to 5.18.0-RC0Ricardo Signes2013-05-071-1/+1
| | | | | | | | This was done with: ./perl -Ilib Porting/bump-perl-version -i 5.17.12 5.18.0 Followed by two tiny manual edits: INSTALL and patchlevel.h
* Add support for building with VC++ 2012Steve Hay2013-01-031-7/+7
| | | | | No code changes seem to be required, so it's just a matter of noting that we've tried it, it works, and we'll support it :-)
* bump version to 5.17.0Ricardo Signes2012-05-201-1/+1
|
* bump version to 5.16.0 RC0Ricardo Signes2012-05-101-1/+1
| | | | | | | | Done with: ./perl -Ilib Porting/bump-perl-version -i 5.15.9 5.16.0 ...followed by a small edit to INSTALL and patchlevel.h.
* Add links to Windows documentation of shell and CRT quote parsing rulesSteve Hay2011-09-111-9/+12
|
* The Borland Chainsaw MassacreSteve Hay2011-09-101-45/+7
| | | | | Remove support for the Borland C++ compiler on Win32, as agreed here: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg00034.html
* [perl #91354] win32/makefile.mk needs patching for gcc-4.x.xSisyphus2011-05-221-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current win32/makefile.mk wants us to edit it when we are using the gcc-4.x.x compiler. Firstly, we have to signify that we are using gcc-4.x.x, then we have to nominate (from a supplied list) the name of the helper dll that needs to be copied to the t folder (in order that the taint.t tests can pass). The supplied list of candidates is deficient - the name of the helper dll from one of my gcc compilers is not listed there. Also, I'm now finding that a second dll (libstdc++-6.dll) needs to be copied to the t folder - otherwise the taint.t test still crashes. The attached makefile.mk patch addresses these issues in such a way that we don't have to do any editting (re the using of gcc-4.x.x) of the makefile.mk at all. There's a small discussion about this on the p5p mailing list in the thread "win32/makefile.mk patch" (15 may 2011). This change to the makefile.mk means that README.win32 needs a slight modification - and the attached README.win32 patch addresses that issue. The README.win32 patch also alters the link to the 64-bit (mingw64) compiler made available by kmx. This has nothing to do with the subject of this bug report, but I don't see why that correction to the link (as suggested to me by kmx, in private correspondence) can't be made.
* Bump the perl version in various places for 5.15.0David Mitchell2011-05-181-1/+1
|
* First provisional bump to 5.14.0-RC0Jesse Vincent2011-04-021-1/+1
|
* Fixup errno definitions for WindowsJan Dubois2011-03-191-12/+1
| | | | | | | | | Redefine all winsock based Exxxx error constants used in the core: For VS2010 we don't want to use the errno.h values, and for older compiler versions we don't have a definition anyways. Also remove the warnings about VS2010 from README.win32, as they should all be resolved now.
* [perl #82706] Tidy up README.win32 pod.Michael Stevens2011-01-241-18/+25
| | | | Surround http:// links with L<> and tidying up lists slightly.
* Always build with crypt() support on WindowsJan Dubois2010-12-071-10/+0
| | | | | | | | 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.
* Windows 95 Chainsaw MassacreJan Dubois2010-12-021-22/+14
| | | | | Remove all supporting code for Windows 9x and Windows NT. The minimum supported version is Windows 2000 now.
* Note that support for building with VC++ 2010 is not yet completeSteve Hay2010-11-181-1/+12
|
* Support Visual C++ 2010Steve Hay2010-11-181-20/+15
| | | | | Also add a couple of things to win32/makefile.mk which were only previously applied to win32/Makefile
* Don't mention Activeware Perl versionsJan Dubois2010-08-061-21/+0
| | | | | | All Win32::* modules on CPAN now build with standard toolchain commands; there is no need for "porting" or special build instructions anymore.
* Drop references to obsolete MinGW 1.x (gcc 2.95)Jan Dubois2010-08-061-48/+5
| | | | | | | 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.
* Platform name is Windows, not Win32Jan Dubois2010-08-061-61/+42
| | | | | | 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!
* Bump to 5.13.0Jesse Vincent2010-04-121-1/+1
|
* Specifying when the trimmed down Win64 compiler works.Curtis Jewell2010-04-021-0/+2
|
* Updating location of Strawberry's 64-bit toolchain.Curtis Jewell2010-04-021-1/+1
|
* Bump to 5.12.0Jesse Vincent2010-03-141-1/+1
|
* Add mingw64 supportSisyphus2009-11-091-5/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Visual C++ 2008 Express Edition is now out: update README.win32Steve Hay2008-02-201-9/+6
| | | p4raw-id: //depot/perl@33335
* RE: [PATCH] s/perl510/perl511/gJan Dubois2007-12-251-1/+1
| | | | | | From: "Jan Dubois" <jand@activestate.com> Message-ID: <0cdf01c84684$f99c3310$ecd49930$@com> p4raw-id: //depot/perl@32722
* Rename "perl59" to "perl510"Jan Dubois2007-11-201-1/+1
| | | | | | From: "Jan Dubois" <jand@activestate.com> Message-ID: <03cd01c82b07$581a1950$084e4bf0$@com> p4raw-id: //depot/perl@32411
* Add support for Visual C++ 2008 Express Edition (Beta 2)Steve Hay2007-08-291-4/+33
| | | p4raw-id: //depot/perl@31761
* Update references to Win32's Platform SDK installation location.Marvin Humphrey2007-07-091-9/+23
| | | | | | | | | 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
* Fix the ext/IO/t/io_sock.t failure when built with VC++ 2005Steve Hay2007-05-251-6/+1
| | | | | | | | | | | | | 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
* Building with Visual C++ 2005 now works except for one test failureSteve Hay2006-11-281-7/+11
| | | p4raw-id: //depot/perl@29409
* Updates for building on Win32 with Visual C++ 2005 Express EditionSteve Hay2006-10-101-10/+57
| | | | | | | | | | | | | 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
* RE: [PATCH, no, really!] Re: [perl #38779] NAN's on Win32Jan Dubois2006-03-231-7/+1
| | | | | | | | | 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
* Re: [perl #38779] NAN's on Win32Dominic Dunlop2006-03-221-1/+7
| | | | | Message-Id: <E44A2151-DE7F-4C5D-8A4B-DDA0412229C2@mac.com> p4raw-id: //depot/perl@27567
* Additions to README.win32 and win32/Makefile based on comments fromSteve Peters2006-03-151-0/+2
| | | | | Steve Hay. p4raw-id: //depot/perl@27503
* Make building perl on Win32 with the free VC++ toolkit easierSteve Hay2005-09-301-11/+10
| | | | | | | | | | | | | 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
* Resolve [perl #37110]: Update README.win32Steve Hay2005-09-201-12/+8
| | | | | | | 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
* Update README.win32Steve Hay2005-06-161-9/+10
| | | | | (Mention Borland compiler is also free; update libwin32 link) p4raw-id: //depot/perl@24868
* RE: a bit of trouble with compiling with MSVC++ on Win32Vadim Konovalov2005-06-071-12/+20
| | | | | | From: "Konovalov, Vadim" <vkonovalov@spb.lucent.com> Message-ID: <7DD1BE2C50259746ABB8683672D2089E12D462@itotest-1.spb.lucent.com> p4raw-id: //depot/perl@24719
View Lorry Controller Status