| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
(Support was added by commits 58998b2a91, 82cad14406, 74102a88af and
88b1365899.)
(cherry picked from commit d8efeb4672ed789e8b5d885676607ec8487984d5)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the rewritten CRT in this version of Visual C++ it is no longer
possible (or at least not at all easy) to make use of the ioinfo struct,
which commit b47a847f62 (re-)introduced in order to fix RT#120091/118059.
Therefore, we effectively revert commit b47a847f62 for VS2015 onwards on
the basis that being able to build with VS2015 onwards is more important
than the RT#120091/118059 bug fix. This does unfortunately mean that perls
built with <=VS2013 will not be compatible with perls built with >=VS2015,
but they may well not have been compatible anyway because of the CRT
rewrite, and certainly wouldn't be compatible if perl builds with VS2015
were not supported!
See RT#125714 for more discussion about this.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
-copy things from makefile.mk to GNUmakefile
-rework CFG_VARS to escape "s. Previously on gmake GCC builds, all "s
inside the CFG_VARS vars were dropped from Config_heavy.pl due to
command line parsing (dmake uses --cfgsh-option-file and a temp file,
nmake escapes). Due to gmake's very poor temp file handling, keep it as
a cmd line and dont convert it to a temp file. What vars to escape was
modeled on the nmake makefile.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-.UPDATEALL is dmake only, doesn't exist in gmake, create more targets
instead
GNUmakefile:1319: warning: overriding recipe for target '.UPDATEALL'
GNUmakefile:1024: warning: ignoring old recipe for target '.UPDATEALL'
-fix ok/nok targets on dmake and gmake
-dont delete old mini config.h, the copy overwrites it, for dmake and gmake
1 less process to run this way
-modify whitespace and comments between 2 makesfiles so there are less
delta lines if the 2 are diffed, this aids in diagnostics
-remove perlmainst.c/perlmain.c build products, just use runperl.c directly
1 less disk file to create and later clean and git status and 2 less nodes
in the make graph to traverse, also better for C debugger, since
"runperl.c" is around after a git clean of the source tree, and runperl.c
is in every single callstack in perl.
-remove copying mini config.h to CORE dir, pointless since (mini) config.h
isn't an input to config_h.PL, remove the exit 1 from commit 137443ea0a
from 5.003, rewriting config.h is not a reason to stop the build with a
fatal error, vivify CORE dir or else sub copy() fails
-deshell UNIDATAFILES/mktables, 1 less cmd.exe process and 1 less .bat file
written to disk for gmake (dmake always uses cmd.exe ATM)
-combining mini config.h AKA $(MINIDIR)\.exists shell append lines is for
another commit
-perlglob.exe is not installed, it doesn't need to be rebased, it is only
needed for module building, removing the dep makes the dep graph simpler
-rename PERLIMPLIB so the lib is built in its final location in CORE dir
this removes an extra xcopy process run. Since perl dll's .a/.lib
is not longer in the root of the source tree, change the 2 tests and
ExtUtils::CBuilder::Platform::Windows to look at the uninstalled final
location dir, not the root dir
-fix typo 0.282224->0.280224 in dist/ExtUtils-CBuilder/Changes
-for GCC PERLEXPLIB must be used, passing "perldll.def" on cmd line to g++
means all data globals with EXTCONST are exported (which have dllexport
on their declaration) instead of just what is in perldll.def and
globvar.sym, INTERN/EXTERN.h could be revised to fix that, but I am not
doing that at this time. Also drop linking GCC perl523.dll from 3
processes to just 1 process like with VC builds. Removing 2nd run of
dlltool fixes a race condition where libperl523.a was generated twice.
This caused a race condition failure where linking a XS DLL failed
because the GCC linker of the XS DLL saw a partially written
libperl523.a.
-Relocation was tested with $(LINK32) -v -mdll -o $@
-Wl,--disable-auto-image-base -Wl,--image-base -Wl,0x400000
$(BLINK_FLAGS) $(PERLDLL_OBJ) $(shell @type Extensions_static)
$(LIBFILES) $(PERLEXPLIB)
to g++ linker to force an address conflict and verified with VMMap
(unrelocated perl523.dll has ~40KB private memory, relocated has ~240KB
private memory on Win 7 32b), historically there are problems with
dllexport and dlltool and relocation problems with mingw
-$(COREDIR)\ppport.h in gmake is separate lines since gmake normally
launches processes directly, not through the shell, so it is more
efficent to keep it as multiple lines for gmake, while dmake likes to
burn CPU and IO between each line, and runs each line through cmd.exe
-disable parallel building in make_ext.pl by not passing MAKEFLAGS env
var to any subprocess, EUMM is not ready for parallelness inside a module
building on Win32
-have harness proc and child .t procs share same disk perl.exe and
perl523.dll files, this way they share memory pages, makefile.mk does
the same thing
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-the first arg of win32_get_privlib is not used if the registry is not
queried, create a macro to allow the arg to drop out on WIN32_NO_REGISTRY
builds for efficiency and not to have unused C litteral strings in the
binary
-This patch changes the ABI of
PerlEnv_lib_path/PerlEnvLibPath/win32_get_privlib between USE_NO_REGISTRY
and no USE_NO_REGISTRY. Since win32_get_privlib is not exported from
perl523.dll, assume it and PerlEnv_lib_path are not public API, note
technically PerlEnv_lib_path will be callable only on PERL_IMPLICIT_SYS
builds, on no PERL_IMPLICIT_SYS builds it will fail at link time since
win32_get_privlib isnt exported. Therefore place it in
non-[affecting]-binary compatibility even though it does affect binary
compatibility.
-delay load advapi32.dll to save startup time (loading the DLL and the DLL
calling its initializers in DllMain) and one 4 KB memory page for
advapi32's .data section (doing "perl -E"sleep 100" on WinXP shows
advapi32 has a 20KB long .data section, first 4 KB are unique to the
process, the remaining 16KB are COW shared between processes according
to vmmap tool), putting a DebugBreak() in pp_getlogin and doing a
"nmake all" shows miniperl never calls getlogin during the build process.
An nmake test shows only ext/POSIX/t/wrappers.t and lib/warnings.t execute
pp_getlogin. Keeping advapi32.dll out of the perl process requires
removing comctl32.dll, since comctrl32.dll loads advapi32.dll, from perl
which I always do as a custom patch.
filed as [perl #123658]
XXXXXXXXXXXXXXXXXXXXXXX
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
