summaryrefslogtreecommitdiff
path: root/win32
Commit message (Collapse)AuthorAgeFilesLines
* Switch most open() calls to three-argument form.John Lightsey2016-12-236-13/+13
| | | | | | | | | | Switch from two-argument form. Filehandle cloning is still done with the two argument form for backward compatibility. Committer: Get all porting tests to pass. Increment some $VERSIONs. Run: ./perl -Ilib regen/mk_invlists.pl; ./perl -Ilib regen/regcharclass.pl For: RT #130122
* Bump the perl version in various places for 5.25.9Sawyer X2016-12-203-3/+3
|
* New perldeltaSawyer X2016-12-204-6/+10
|
* Bump the perl version in various places for 5.25.8Chad Granum2016-11-203-3/+3
|
* new perldeltaChad Granum2016-11-204-6/+10
|
* No default breaks win32 and VMSH.Merijn Brand2016-11-123-3/+3
|
* Remove "." from default @INC when default_inc_excludes_dot is setH.Merijn Brand2016-11-113-0/+3
| | | | | | | | | | | | | | | | Perl now provides a way to build perl without . in @INC by default. If you want this feature, you can build with -Ddefault_inc_excludes_dot Because the testing / make process for perl modules do not function well with . missing from @INC, Perl now supports the environment variable PERL_USE_UNSAFE_INC=1 which makes Perl behave as it previously did, returning . to @INC in all child processes. WARNING: PERL_USE_UNSAFE_INC has been provided during the perl 5.25 development cycle and is not guaranteed to function in perl 5.26. Update unit tests and default value files to work with the new %Config variable "default_inc_excludes_dot"
* Configure: add defs summarizing doublekind/longdblkindJarkko Hietaniemi2016-10-286-0/+147
| | | | | | | | | | For windows/netware It seems that many of the recent fp definitions have not been yet copied over there [1] [2], so went mostly by dead reckoning [3]. [1] Note that many of them are not absolutely necessary for building. [2] The proper updating involves doing stuff in win32, which I do not have. [3] As far as I can tell, Windows CE does not really not have long double.
* Bump version numbers ready for 5.25.7Aaron Crane2016-10-203-3/+3
|
* New perldelta for 5.25.7Aaron Crane2016-10-204-6/+10
|
* bumping the version number Stevan Little2016-09-243-3/+3
|
* Change sv_setpvn(…, "…", …) to sv_setpvs(…, "…")Dagfinn Ilmari Mannsåker2016-09-211-1/+1
| | | | | The dual-life dists affected use Devel::PPPort, so can safely use sv_setpvs() even though it wasn't added until Perl v5.10.0.
* new perldeltaStevan Little2016-09-204-6/+10
|
* tweaks for Win32 VC vs GCC detection makefile codeDaniel Dragan2016-08-242-43/+53
| | | | | | -fix issue that CCHOME depends on CCTYPE, which in auto detect mode is set after CCHOME so CCHOME uses uninit CCTYPE var -also fix else vs .ELSE in makefile.mk
* Bump the perl version in various places for v5.25.5Chris 'BinGOs' Williams2016-08-203-3/+3
|
* New perldeltaChris 'BinGOs' Williams2016-08-204-6/+10
|
* automatically detect GCC vs VC and set VC ver number on Win32Daniel Dragan2016-08-142-7/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a bug, if you use gmake, without a GCC in PATH (but you do have a VC in PATH) GNUMakefile is unusable because target info fatally errors. I usually keep a strawberry perl's /c/bin dir in PATH for dmake and gmake on my VC builds, but in 1 build config, I installed gmake to my C:/Windows dir and did not have SP's /c/bin dir in my PATH, so GNUMakefile was broken in that case. This patch fixes the bug. -move the gcc -dumpversion shell outs to the GCC only section in both mkfs dont run gcc -dumpversion on a VC build -dont have a default CCTYPE anymore, autodetect it, if user supplies CCTYPE explicitly on cmd line to make tool, then dont do autodetection (its faster by 50-100ms to manually specify CCTYPE not call gcc.exe and cl.exe with the auto detect code), "FREE" detection is unimplemented but seems to make no difference with VC except for an old rare "free" VC 2003 I personally use a paid VC 2003. -silence console messages and warnings from a missing gcc.exe causing "gcc -dumpmachine" to warn or fatally error, gmake doesn't care about exit code, dmake does -on dmake, use := instead of *= or =, otherwise the long for loop shell line runs dozens of times (multiple eval problem) -on dmake, since GCCBIN macro doesn't exist and dmake mfk is "simpler" than gmake just call gcc.exe always and not a prefixed version of GCC for the GCCTARGET macro, it isn't used outside the autodetection code anyways and if a user neglected to specify CCTYPE it is assumed they neglected to specify GCCCROSS too
* Add probe for gai_strerrorH.Merijn Brand2016-08-113-0/+3
|
* forgot the cfgvarH.Merijn Brand2016-07-283-0/+3
|
* (perl #128438) build ppport.h instead of using a dummy fileTony Cook2016-07-283-19/+23
| | | | | | | | | | | | | | The changes to parallelize win32 perl builds with dmake and gmake assumed that ppport.h only provided macros and functions that are already provided by the latest perl. This turns out not to be the case, preventing the building of a new Scalar-List-Utils with dmake and gmake. I only briefly considered changing Scalar-List-Utils - the difference in build systems is what lead to the failure, so properly build ppport.h so that all Win32 builds have a full ppport.h just as POSIXish builds do.
* Bump version to 5.25.4Steve Hay2016-07-203-3/+3
| | | | (including regen/opcode.pl)
* Create new perldelta for 5.25.4Steve Hay2016-07-204-6/+10
|
* Bump the perl version in various places for 5.25.3Matthew Horsfall2016-06-203-3/+3
|
* Add new perldeltaMatthew Horsfall2016-06-204-6/+10
|
* Add Configure probe for strerror_l()Aaron Crane2016-06-023-0/+3
| | | | | | | | | As requested by khw++ Until the relevant symbol is used, HAS_STRERROR_L must be mentioned explicitly in metaconfig.h. This corresponds to metaconfig d0838744f03cfe7642950ea91dd48f575d0bfd15.
* Add Configure probe for querylocale()Aaron Crane2016-06-023-0/+3
| | | | | | | | | As requested by khw++ Until the relevant symbol is used, HAS_QUERYLOCALE must be mentioned explicitly in metaconfig.h. This corresponds to metaconfig 541f0dd272df4f9326996727898393ac8f6626f7.
* allow ext/XS-APItest/t/win32.t to pass with both E: and T: drivesTony Cook2016-06-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Encountered while testing locally on Windows 7 x64. cmd.exe stores the current directory for each drive as entries in the environment, like: C:\Users\tony>set "" | findstr "^=" =::=::\ =C:=C:\Users\tony =D:=D:\ASM1061 When a Win32 build of perl built with USE_IMP_SYS starts up it saves the current directories of each drive in a per-thread structure so that each pseudo-forked process can have it's own set of drive current directories. If you run an external command, some versions of cmd.exe will add an entry to the environment storing the result of that command, for example: C:\Users\tony>set "" | find "ExitCode" C:\Users\tony>git status fatal: Not a git repository (or any of the parent directories): .git C:\Users\tony>set "" | find "ExitCode" =ExitCode=00000080 which is similar to the current directory entries. The sloppy parsing by VDir::FromEnv[WA]() would treat that as a current directory entry for the E: drive, copying the "tCode=...." into the current directory. Normally these values include a leading drive letter and \, like "E:\", but this case leaves us without that. Later, when harness spawns the child process it builds a new environment block, including the drive current directories, which is done by VDir::BuildEnvironmentSpace(). This, rather than using the index of the drive to build the "=C:=..." entries above, uses the first letter of the stored entry, so the environment block would have something like: t:=tCode=00000080 which the child perl would treat as the current directory for the T: drive.
* Bump the perl version in various places for 5.25.2Sawyer X2016-05-213-3/+3
|
* new delta for 5.25.2Sawyer X2016-05-214-6/+10
|
* update GNUmakefile for Test2 tooTony Cook2016-05-121-0/+1
|
* Update to the latest Test-Simple cpan distChad Granum2016-05-122-0/+2
|
* perldelta: new v5.25.1 perldeltaRicardo Signes2016-05-094-6/+10
|
* bump version to v5.25.1: now open for businessRicardo Signes2016-05-093-3/+3
|
* perldelta: add perl5250deltaRicardo Signes2016-05-084-6/+10
|
* bump version to v5.25.0Ricardo Signes2016-05-084-27/+27
|
* Import 5.22.2's perldeltaSteve Hay2016-04-301-0/+4
|
* remove the v5.23.x perldeltasRicardo Signes2016-04-131-40/+0
|
* fix versions of generated perldeltaRicardo Signes2016-04-104-10/+10
|
* version bump: this is now v5.24.0-RC0!Ricardo Signes2016-04-104-27/+27
|
* Add locale mutexKarl Williamson2016-04-092-0/+2
| | | | | This adds a new mutex for use in the next commit for use with locale handling.
* Add probe for memmemH.Merijn Brand2016-03-253-0/+3
|
* Bump version in various placesAbigail2016-03-203-3/+3
|
* New perldeltaAbigail2016-03-204-6/+10
|
* Add Configure probes for newlocale, freelocale, and uselocaleH.Merijn Brand2016-03-193-0/+9
|
* Upgrade Win32API::File from version 0.1202 to 0.1203Steve Hay2016-03-193-0/+3
| | | | | | Fixes perl #125303. (Includes a regen for the moved Myconst2perl.pm.)
* Set $^E for socket errors on WindowsSteve Hay2016-03-111-12/+19
|
* [perl #127584] using Win32 32b gmake with 64b gcc caused wrong archnameDaniel Dragan2016-02-291-2/+2
| | | | | | | | | Using a 32 bit Win32 gmake, with a GCC that produces 64 bit binaries, made a perl with PTRSIZE 64 bits, and 64 bit machine code, but archname IDed that build as "x86" not "x64", which is very wrong. Perl's win32/GNUMakefile autodetects the bitness of the GCC and sets things up accordingly. Fixes [perl #127584]. This bug might be a regression introduced in commit 745dedb9b5 or the GNUMakefile parallel build branch.
* bump version to 5.23.9Sawyer X2016-02-203-3/+3
|
* new perldelta for 5.23.9Sawyer X2016-02-204-6/+10
|
* fix win32 gmake with win64 VC with 32 bit GCC in PATH build failureDaniel Dragan2016-02-151-9/+11
| | | | | | | | | | | | | | | The assignment of PROCESSOR_ARCHITEW6432 to PROCESSOR_ARCHITECTURE near the "When we are running from a 32bit cmd.exe on AMD64 then" comment doesn't happen if WIN64 var was already assigned to. Do the 32/64 auto detection only for GCC builds, not for VC builds. I not implementing 32/64 and cl version (CCTYPE setting) detection by parsing stdout of "cl<enter>" with batch and gmake syntax at this time. failure message: generate_uudmap.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' GNUmakefile:1416: recipe for target '..\generate_uudmap.exe' failed gmake: *** [..\generate_uudmap.exe] Error 2
View Lorry Controller Status