| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
No code changes are needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also remove the Platform SDK 2003 SP1/R2 64-bit compiler since (having just
tried it) it no longer builds perl because it doesn't allow mixed code and
declarations.
Also remove mention of the Windows SDK since it doesn't appear to contain
the compiler or linker any more. This page says that the VC++ 2010 compiler
and linker were included in the Windows 7 SDK but then makes no mention of
it for the Windows 8 SDK:
https://docs.microsoft.com/en-us/previous-versions/visualstudio/windows-sdk/ff660763(v=vs.110)
The page notes that it is no longer being updated, but the whole of the
C:\Program Files (x86)\Windows Kits folder on my system (which contains
8.0, 8.10 and 10) does not contain any cl.exe or link.exe.
I've re-worded some of the if/else conditions in the makefiles to pick out
earlier versions rather than later versions. Thus, the current versions
become the "else" case, which means that the next version of Visual C++ is
more likely to work without requiring any changes.
|
| |
|
|
|
|
|
|
|
|
| |
* Remove specific notes related to Microsoft Visual C++ 2005 Express Edition
and earlier
* Visual Studio 2013 is the only version that still has Express edition (in
addition to Community), so simplify the text by only mentioning Community
* Remove the reference to IA64, and mention x86_64 along with x86
* In the context of x86_64, clarify that mingw's binaries can run on both
* Update the URL for mingw
|
| |
|
|
|
|
| |
* Apparently, first you bump, then you update perldelta.
* 5.35.0 *might* be released tomorrow (likely) but not certainly.
* I've set it to tomorrow so Module::CoreList won't be upset.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Makefile.mk is redundant with GNUmakefile. See
https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258848.html
for more details.
We planned to remove it shortly after the introduction of GNUmakefile
but that slipped through the cracks for some reason:
https://github.com/Perl/perl5/issues/14341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MinGW runtime version 3.21 added a definition of mkstemp(), so requires a
fix similar to f33b2f5852 for MinGW-w64's runtime 4.0 onwards.
Based on a patch by Dan Collins on GH#15446.
This commit also tweaks 43b3b04375, having discovered that mingw runtime
3.22 also contains a definition of timespec.
For me, this fixes the build with my mingw.org 5.3.0 compiler using any of
the mingw runtimes 3.21, 3.22.4 or 5.0 without breaking older versions such
as 4.9.3 with the 3.20 runtime (or even with the withdrawn 4.0.3 runtime,
which had __MINGW32_MAJOR/MINOR_VERSION set to 3.20 whilst adding new a
__MINGW_MAJOR/MINOR_VERSION set to 4.0).
However, 6.3.0 and 7.3.0 have other issues when compiling win32sck.c, while
8.2.0 and 9.2.0 have other issues again when compiling win32.c. See
GH#18510 for more details.
Also, C++ mode builds with some MinGW/MinGW-w64 compilers are still broken,
as documented in 8a217c9aa7. See GH#16459 for more details.
|
| |
|
|
|
|
|
|
|
| |
For: https://github.com/Perl/perl5/pull/18201
Committer: Samanta Navarro is now a Perl author.
To keep 'make test_porting' happy: Increment $VERSION in several files.
Regenerate uconfig.h via './perl -Ilib regen/uconfig_h.pl'.
|
| | |
|
| | |
|
| |
|
|
|
| |
Mostly in comments and docs, but some in diagnostic messages and one
case of 'or die die'.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There were a number of spots that used language more appropriate for an email
address than a web-based tracker.
I noticed this because of the recent 5.30.2 release, which has a perldelta
containing the sentence "If you find any we have missed, send email to
https://github.com/Perl/perl5/issues."
But I think that was because the 5.30.2 branch did not include
8166b4e0bc220e759aa233af54ac1e60cc510f0c.
|
| | |
|
| |
|
|
|
|
| |
GitHub issue tracker
The perlbug utility and perlbug@perl.org should no longer be used to submit bug reports or patches.
|
| |
|
|
|
| |
Remove MS Visual C++ 6.0 support as agreed in the thread starting here:
https://www.nntp.perl.org/group/perl.perl5.porters/2019/07/msg255625.html
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This also fixes LINK_FLAGS for VS2017 (Visual C++ 14.1): The subsystem
setting was missed in the changes to add VS2017 support, which was surely
just an oversight.
|
| |
|
|
|
|
|
|
|
|
|
| |
README.win32 provides generally standalone instructions for running
and testing perl, but unlike INSTALL didn't provide instructions
for repeating individual tests.
Both perlguts and INSTALL provide instructions on repeating individual
tests, and considering at the point a user want this information they
don't have a working perl installation, I think it's reasonable to
repeat it here.
|
| |
|
|
|
|
|
|
| |
Committer: For porting tests: Update $VERSION in 4 files.
Run:
./perl -Ilib regen/mk_invlists.pl
./perl -Ilib regen/regcharclass.pl
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
See [perl #128631] (MinGW with runtimes >= 3.21 currently don't work) and
[perl #132955] (MinGW 3.4.5 and 4.7.2+ and MinGW64 x64 6.3.0+ currently
don't work in C++ mode).
|
| | |
|
| |
|
|
|
|
|
| |
As was pointed out recently in perl #131487, there is little point in most
of these since the Express (now Community) versions are so close to the
full versions anyway these days. MSVC70FREE is retained since it was the
only one that was actually being made use of.
|
| |
|
|
|
| |
(Support was added by commits 58998b2a91, 82cad14406, 74102a88af and
88b1365899.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
