| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This stops each ENV var lookup (and 16 calls to get_regstr, most of which
are %ENV lookups, are done automatically each time a Win32 Perl process
starts) from querying the registry for usually failing lookups.
ActiveState is the only known major user of the Software/Perl reg key.
details:
-cache the root handles, so a typically failing env var lookup does only 1
system call instead of 3 if the parent key exists
-if the key exists, looking it up is slightly faster since it is 4
registry syscall instead of previously 6 (open "*\Software\Perl", 2
RegQueryValueExAs(on "found" behavior each RegQueryValueExA does 2
RegQueryValueExW calls), close "*\Software\Perl")
-dont make a system call to lookup a value if the parent key doesn't exist
-change "Software\\Perl" to "SOFTWARE\\Perl" since the reg is case
preserving but lookups are not case sensitive, this all caps casing is
what regedit shows, and might save a couple cpu cycles in the DB lookup
in the kernel
-use RegOpenKeyExW instead of RegOpenKeyEx (actually RegOpenKeyExA), this
avoids ansi to utf16 conversions at runtime
-dont check HKEY handles for NULL before calling RegCloseKey.
MS and ReactOS RegCloseKey checks for NULL (zero) handle first thing and
returns ERROR_INVALID_HANDLE as the retval of RegCloseKey. MS App Verifier
does not complain about NULL handles.
-Dont check the retval of RegCloseKey, there is no way to dispatch an error
at this point in the process, there are no interps, and no perlio, and
maybe no console if its a GUI, and the process is probably exiting anyway.
Calling Perl_noperl_die (no perl, no perlio, print to stderr) would not
be friendly to an embedder. A crash box with RaiseException with
EXCEPTION_INVALID_HANDLE is a bad UI.
-Dont bother to zero the HKEY handles, after a PERL_SYS_TERM until the
next (if any) PERL_SYS_INIT3, libperl is in an undefined state, it is the
embedders responsibility to refcount and serialize calls to
PERL_SYS_INIT3/PERL_SYS_TERM if necessary
See details in [perl #123658]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-reonly/Extensions_reonly target, which is never used, didn't work in
parallel because it was using left to right execution of an upstream dep
to create build products, that is incompatible with parallel building, fix
by trimming down the list of deps, $(UNIDATAFILES) and Extensions_reonly
know how to build themselves
-regnodes psuedotarget is redundant, it is just an alias for ..\regnodes.h
which isn't a build product, remove regnodes and just use ..\regnodes.h
instead, smaller build graph/less parsing for dmake tool
-I am not questioning relationship between reonly, ..\regnodes.h,
..\regcharclass.h, ..\regcomp.o, $(UNIDATAFILES), Extensions_reonly
since regnodes.h and regcharclass.h are git tracked files and not build
products, and things work well enough as is
-perlglob.exe is needed to build extensions, the natural race conditions
that exist in parallel building ment that it was usually getting built
early enough that it being missing wasn't noticed, and "rebasePE" target
made sure it existed eventually. Some Makefile.PLs indirectly warned that
perlglob was missing from the cmd.exe complaining about perlglob being
missing but didnt cause an non-zero to happen from the Makefile.PL
process. Also since perlglob.exe is installed into the final installed
perl, probably pointlessly since full perl is not built with
PERL_EXTERNAL_GLOB I think an installed perl's perlglob.exe was being
used when I developed commit 3bdc51af3f and related patches. Since re,
DynaLoader, and lib are a very limited fixed list of modules, and they
dont need perlglob.exe, they dont need to get it as a dep.
-reorder the deps in Extensions_static and Extensions_nonxs so permanent
files, rarely changed files are on the left side, and build products are
on the right. Maybe some kind of optimization happens inside dmake due to
the first couple deps being already built (because they are permanent).
-remove ..\lib\buildcustomize.pl dep, it is redundant. Its other name is
HAVEMINIPERL, and CONFIGPM can't exist without miniperl. Less nodes in
dmake's internal graph, since dmake's dep finding algorithm is very
inefficient and repetitive.
-gmake is supported since commit 342634f3c8 but GNUmakefile doesn't
support parallel (-j) building
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-if building a 32 bit Perl, with a 64bit dmake, force
PROCESSOR_ARCHITECTURE to x86, otherwise the next couple macros will
try to build a 64 bit perl with 32 bit CCs
-PDBOUT is required to run multiple VC cl.exe processes, otherwise all
VC cl.exe processes will error out trying to lock and write to a
file called "vc*0.pdb", PDBOUT is empty for GCC builds since they dont
have PDB files
-to reduce excess IO calls checking for miniperl.exe plus remove a
"Found file corresponding to virtual target" warning that dmake emits,
make this makefile unaware that miniperl.exe exists. dmake has a very bad
exponential number of IO/stat() calls for every target that is yet
unbuilt, see procmon logs in [perl #123854], so instead of a stat on
../miniperl.exe, then ../lib/buildcustomize.pl, it will be just a stat on
../lib/buildcustomize.pl
-remove makefile awareness of ..\lib\Config_heavy.pl,
if ..\lib\Config_heavy.pl is ever updated, so is ..\lib\Config.pm
less IO calls for dmake, see also commit 962e59f394
-to break up the sequential nature of this makefile, allow (XS) Extensions
to build, before (AKA parallel with) perl5**.dll and perl.exe are built.
This is achieved by running makedef.pl very early, and generating
perl5**.lib/libperl5**.a from the def file, and NOT generating
perl5**.lib/libperl5**.a from perl5**.dll at link time of perl5**.dll.
The conquence of this is, declspec(dllexport) is now unusable, but exports
should be centrally managed anyways (embed.fnc/etc) so this isn't a big
issue.
-EUMM makefiles shouldn't be subject to parallelism, untested and disable
for now, plus creating PLMAKE allows "dmake -n" to work for diagnosing
this makefile
-slim down all target. Extensions* and UNIDATAFILES now know how to build
themselves, the parallel nature says you can't rely on left to right
execution of deps in a parent node to make a child (dep) node build
-miniperl.exe used to be unbuildable from a clean tree except from all
target, since miniperl.exe didn't depend on mini config.h. Also mini dir
can't be a target, since each .obj built will dirty the mini dir's time
stamp and infinite loop happens, instead use a .exists file
-dmake rescans for all outstanding targets, at each recipe line to run,
this early in the build process, there are an enormous amount of files to
test for, so the echos are very slow, 350ms each, so combine as many of
the lines of mini/.exists AKA mini config.h together as possible. ".IF"
can't be put inside "one line", so not all lines were merged. Shell "if"
could be used to further group the echos but this enough to make the pause
/cpu spining not really noticable. USE_CPLUSPLUS contains an unrolled line
(the #endif) on both sides. See also procmon logs in [perl #123854]
-perllib.obj/.o needs perllibst.h which is built by miniperl+a script,
perllibst.h target doesn't need any Extensions*, so perllib.obj is still
quick to build
-perldll.def doesn't need perllibst.h since makedef.pl uses
$Config{static_ext} to find boot xsubs to export, makedef.pl does not
read perllibst.h, remove perllibst.h for more parallelism/less things to
build before perldll.def runs, and therefore Extensions (XS) starts to
run quicker, and Extensions (XS) is the longest target to build
-perlmain and perlmainst .obj/.o needs full perl headers to compile, they
aren't like generate_uudmap.exe and perlglob.exe which are perlapi unaware
-perl.exe doesn't need perl5**.dll to build, just the imp lib to
perl5**.dll, perl.exe is in the same category as XS modules, more
parallelism
-ppport.h isn't needed in blead perl, since blead is the newest perl in the
world, this allows Extensions (XS) to run sooner, ppport.h is replaced by
a dummy empty file, delete ppport.h from final installed CORE dir during
installation so the dummy ppport.h doesn't wind up in installed perl and isnt
seen by CPAN XS modules during their building by the perl user after perl
was build and installed, note mkppport script and mkppport.lst are unused
in makefile.mk now
-break up the dependencies of all the Extensions* targets, static
(just Win32CORE normally), dynamic XS and non-XS, these 3 run in parallel
now, non-XS doesn't need perl5**.lib/.a or any C headers, just PP
Config.pm
-DLL XS requires PP DynaLoader.pm for dl_findfile() otherwise
Mkbootstrap.pm fatally errors, Mkbootstrap.pm could be revised to not load
DynaLoader on Win32, since " if ($Config{'dlsrc'} =~ /^dl_dld/){" is
false, but this is the easier path right now
-DynaLoader requires module lib to build itself, but Extensions_nonxs
happens to not need mod lib, so move where mod lib is built
-in utils target, change it so it can run with miniperl, more parallelism,
pl2bat doesn't require full perl, the full perl stuff is from
commit 3fe9a6f19e from 5.003 and no ML archive is available to explain why
full perl was used instead of mini perl
-add 4 modules to buildcustomize so nonxs and xs build simultaneously
-remove ancient cruft from commit 26618a56da from 1997 from README.w32
dmake is automatically set inside CFG_VARS today. OSRELEASE is irrelavent
today, Perl doesn't use any of the defaults (like name of CC) from the
maketool.
-Reduce 21 calls of "cmd.exe /x/d/c cd" by miniperl to just 1 by saving and
reusing cwd. This reduced the amount of time to run
"..\miniperl.exe -I..\lib -f ..\write_buildcustomize.pl .." from 312 ms
to 62 ms elapsed time using timeit.exe for me.
|
|
|
|
| |
This fixes a bunch of them, but there are many more
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This came up in perl #121643, but I forgot to add a note of this Known
Problem.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
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 :-)
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
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
|