| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
(includes regen/opcode.pl)
|
| | |
|
| |
|
|
| |
(includes regen/opcode.pl)
|
| | |
|
| |
|
|
| |
(includes regen/opcode.pl)
|
| | |
|
| | |
|
| |
|
|
| |
(includes regen/opcode.pl)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Fixes perl #125303.
(Includes a regen for the moved Myconst2perl.pm.)
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
On older VCs a "gmake -j2 ..\generate_uudmap.exe ..\perlglob.exe" will
generate warnings, on newer VCs, a fatal error in 1 or the other cl.exe
process. This is because both cl.exes are trying to lock and write to
vc*0.pdb, the same file. Add PDBOUT option so uudmap and perlglob have
their own pdb files named after themselves and they cant conflict in a
parallel build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The manifestdependency flag caused on VC 2005 and up for all XS DLLs to
include a manifest that references common controls v6 DLL, even though
nothing but perl5**.dll and perl-static.exe would ever link to
comctl32.dll. VC 2005 to VC 2008 put manifests in all DLLs since those
VC version's CRTs require manifests to load, all other VCs generate
.rsrc section free, and manifest free, DLLs by default. The
/manifestdependency flag passed to VC linker for all XS DLL, was causing
52 KB of bloat in disk size of the DLLs, and perhaps a little bit of CPU
to parse the manifest XML when the XS DLL is loaded.
Add a test to make sure the manifest for V6 isn't accidentally broken and
V5 gets loaded instead.
Note this commit leaves a little bit of unequal handling of the comctl
manifest between VC and GCC builds. VC >= 2005 builds with this patch will
add a manifest to perl523.dll and build helpers (not installed)
perlglob.exe and generate_uudmap.exe while GCC builds only manifest
perl.exe and wperl.exe.
With a VC 2013 32b build, before
C:\p523\src>dir /s *.dll
55 File(s) 7,858,688 bytes
After
C:\p523\src>dir /s *.dll
55 File(s) 7,805,440 bytes
|
| |
|
|
|
|
| |
Previously each line was 1 shell process launch. By grouping all the echos
together, CPU and IO are saved by doing alot less cmd.exe process launches.
makefile.mk does the same thing already. See #126632 for benchmark details.
|
| |
|
|
|
|
|
|
|
|
| |
-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
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Instead of #include-ing the C file, compile it normally.
|
| | |
|
| | |
|
| | |
|
| |
|
