| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original implementation in commit cba61fe146 was sloppy. It is named
like a special var, it is listed as a special var, but it was a regular GV.
Since nobody knows this var exists, and full stat is the default (which I
disagree with see below). There will be alot more PP and C/XS perl stat()
calls (atleast a couple to dozens or low 100s for short lived perl
processes) than reads/writes to this global scalar (rounded to 0 R/Ws)
in a Win32 perl process. So avoid the 1 usually failing GV package (hash)
lookup for each PP/XS/PL C stat by using magic vars and a C bool. This is
a perf increase. Use sv_true instead of SvTRUE_NN because this code is
extremely rare to execute and the macro has large machine code.
I disagree with the default being full stat with since this increases the
number of kernel IO calls and ASCII->UTF16 conversions, and there was
perf criticism in the original thread that implemented this
this http://www.nntp.perl.org/group/perl.perl5.porters/2006/02/msg109917.html
but why full stat is default is for another ticket. This patch lessens the
overhead of full stat until something else is decided.
Change the initial value of the sloppystat setting for miniperl to be true
instead of doing it in buildcustomize.pl in PP. Revert part of
commit 8ce7a7e8b0 "speed up miniperl require on Win32" to acomplish this.
Unlike Unix perl, no object files are shared between mini and full perl,
so changing the default is fine on Win32 Perl. If minitest/miniperl really
need hard link testing/support, they can explictly turn off sloppy stat
and enable full stat with the special var. Changing the stat default from
C for miniperl avoids creating the special GV on each miniperl process
start as it previously was with the buildcustomize.pl way.
Changing stat setting in C and not PP also saves a couple IO calls in
win32_stat when opening the first .pl if it isn't -e, and
opening buildcustomize.pl in all permutations. The PP code in S_parse_body
contains a -f. See ticket for this patch for details.
Only CPAN use of this special var is
File-Stat-Moose-0.06/lib/File/Stat/Moose.pm#L208 according to cpangrep.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The front end of PERL_IMPLICIT_SYS is PerlEnv_*/PerlSock_*/PerlProc_*/etc
macros. These are either macroed to C vtable calls when PERL_IMPLICIT_SYS
is on, or to the backend raw win32_*() functions when PERL_IMPLICIT_SYS
is off.
win32_get_*() were not following this convention. All this code looks like
a hack as if someone didn't have perms to edit perl.c, but they did have
perms to edit /win32, so they devise a scheme of hooking "unhooked"
win32_get_*() functions with win32.h macros for win32_get_*() to call the
Perl*() virutalization macros, and rename the original function bodies in
win32.c to g_win32_get_*() as to not make a macro loop.
Undo all of this hack by having perl.c call correct PerlEnv_* macro. This
refactoring will be useful for a future patch in #123658 to disable
win32 registry lookups.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These 2 macros were created for the Symbian port in commit
"Symbian port of Perl" to replace a direct "extern" token. I guess the
author was unaware of PERL_CALLCONV.
PERL_CALLCONV is the official macro to use. PERL_XS_EXPORT_C and
PERL_EXPORT_C have no usage on cpan grep except for modules with direct
copies of core headers. A defect of using PERL_EXPORT_C and
PERL_XS_EXPORT_C instead of PERL_CALLCONV is that win32/win32.h has no
knowledge of the 2 macros and doesn't set them, and os/os2ish.h doesn't
either. On Win32, since the unix defaults are used instead of Win32
specific "__declspec(dllimport)" token, XS modules use indirect function
stubs in each XS module placed by the CC to call into perl5**.dll instead
of directly calls the core C functions. I observed this in in XS-Typemap's
DLL. To simplify the API, and to decrease the amount of macros needing to
implemented to support each platform, just remove the 2 macros.
Since perl.h's fallback defaults for PERL_CALLCONV are very late in perl.h,
they need to be moved up before function declarations start in perlio.h
(perlio.h is included from iperlsys.h).
win32iop.h contains the "PerlIO" and SV" tokens, so perlio.h must be
included before win32iop.h is. Including perlio.h so early in win32.h,
causes PERL_CALLCONV not be defined since Win32 platform uses the
fallback in perl.h, since win32.h doesn't always define PERL_CALLCONV and
sometimes relies on the fallback. Since win32iop.h contains alot of
declarations, it belongs with other declarations such as those in proto.h
so move it from win32.h to perl.h.
the "free" token in struct regexp_engine conflicts with win32iop's
"#define free win32_free" so rename that member.
|
| | |
|
| | |
|
| |
|
|
| |
Extracted from patch submitted by Lajos Veres in RT #123693.
|
| |
|
|
|
|
|
|
|
|
|
| |
As noted in #123394, building without PerlIO was all but deprecated in
5.18.0 and is no longer supported by Configure on POSIX systems, so there
is no need for the Windows makefiles to provide support for it either.
Therefore, we can simply enable PerlIO in the canned configuration files
and remove any fiddling with that setting for the real configuration,
which means that miniperl will also now have PerlIO enabled without
needing the recently added change to win32.h.
|
| |
|
|
|
|
|
|
| |
fixes io/data.t
This could be considered a bug in io/data.t, since it writes the scripts
in text mode, but making miniperl behave closer to perl may fix
other issues too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several tests use PerlIO layers (:utf8, :pop) without testing for it.
non-PerlIO builds were vaguely deprecated in 5.18.0 and can no longer be
enabled on POSIX systems through Configure, so making miniperl PerlIO
on Win32 is no big stretch
minitests failing now:
io/data.t
io/fs.t
op/coreamp.t
op/filetest.t
op/fork.t
op/glob.t
op/heredoc.t
op/magic.t
op/sselect.t
op/stat.t
op/tie_fetch_count.t
|
| |
|
|
| |
and then remove the disabling of that warning.
|
| |
|
|
| |
perl.exp:fake:(.edata+0x1214): undefined reference to `win32_async_check'
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
So that it works with NaN, by not using the comparison version of
Perl_isinf. A little messy but since win32/win32.h is included so
late in perl.h, cannot be done earlier with the other Perl_isinf
logic. Partially reverts 128eeacb.
|
| |
|
|
|
|
| |
These 3 optimizations reduce the number of, usually failing, I/O calls
for each "require" for miniperl only. None are appropriate except for
Win32. See #121119 for details.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Win32 Perls built without PERL_IMPLICIT_SYS, killpg from win32.c was
directly called by Perl_apply, yet killpg's return value had Win32
behavior, not POSIX behavior. Modify killpg token to have same meaning as
PerlProcKillpg/PerlProc_killpg has on PERL_IMPLICIT_SYS builds. Use a
macro rather than create a win32_killpg C function since win32_killpg would
be nothing but a call to win32_kill anyways. win32_kill contains the Win32
to POSIX semantics conversion code. Rename old killpg to my_killpg since
it has no use outside of win32.c. The psuedo-PID code in win32_kill also
played a factor in not writing a separate win32_killpg that calls
my_killpg. This fix is tested by kill0.t passing on
no-PERL_IMPLICIT_SYS builds.
[perl #121230]
|
| |
|
|
|
|
|
|
|
| |
Due to a bug in the CRT (msvcr71.dll), these 2 functions are not defined
in any lib Perl can use (static link CRTs dont apply, Perl only uses DLL
CRTs), but they are available as intrinsics. This solves a link error
about missing symbol __rotl64 in hv.obj, from usage in hv_func.h, on 32 bit
USE_64_BIT_INT VC 2003 builds. _rotr64 is included for completeness. This
fix is filed as [perl #120925].
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is in RT as [perl #120091] but also fixes [perl #118059].
Because the MS C lib, doesn't support sockets natively, Perl uses
open_osfhandle, to wrap a socket into CRT fd. Sockets handles must be
closed with closesocket, not CloseHandle (which CRT close calls).
Undefined behavior will happen otherwise according to MS. Swap the now
closed socket handle in the CRT to INVALID_HANDLE_VALUE. The CRT will
not call CloseHandle on INVALID_HANDLE_VALUE and returns success if it
sees INVALID_HANDLE_VALUE. CloseHandle will never be called on a socket
handle with this patch.
In #118059, a race condition was reported, where accept() failed with
ENOTSOCK, when a psuedofork was done, and connection from the child fake
perl process to parent fake perl process was done. The race condition's
effects occur inside the user mode code in mswsock.dll!_WSPAccept in the
parent perl, which winds up having a kernel handle of an unknown type
in it that is invalid. The invalid handle is passed to kernel calls, which
fail, because the handle is invalid, and the error is translated to
ENOTSOCK. The exact mechanism of the bug and 100% reproducabilty of the
race were never established, since mswsock.dll is closed source.
Another benefit of this patch is making it easier to use C debuggers on
a Win32 Perl because of less debugger-only bad handle exceptions
(NtGlobalFlag FLG_ENABLE_HANDLE_EXCEPTIONS/0xC0000008 STATUS_INVALID_HANDLE).
This commit reverts parts of commit 9b1f18150a
"Get rid of PERL_MSVCRT_READFIX" and parts of commit 46e77f1118
"Don't use the PERL_MSVCRT_READFIX when using VC++ 7.x onwards." and
contains additional changes not found in those 2 commits. The method for
selecting the definition of struct ioinfo isn't perfect. It will break if
VC > 6 is changed to use the older msvcrt.dll. For some versions of the
CRT, like 2005/8.0, it is impossible to know the definition of ioinfo
struct at C compile time, since the struct increased in size a number of
times with higher build numbers of v8.0 CRT. SxS and security updates make
that same perl binary will run with different v8.0 CRTs at different times.
For the case when ioinfo can not be hard coded, introduce
WIN32_DYN_IOINFO_SIZE. With WIN32_DYN_IOINFO_SIZE, the size of the ioinfo
struct is determined on Perl process startup using _mize. Since VC 2013
is a brand new product at the time of this patch, even though its struct
is known, and 2008 through 2012 have been stable so far, don't assume at
this time 2013's ioinfo will be stable. Therefore, VC 2003 and older
(including Mingw's v6.0), 2008 to 2012, are hard coded. 2013 is a candidate
one day to be hard coded. VC 2005 can never be hard coded.
All non-WIN32_DYN_IOINFO_SIZE compilers will work with
WIN32_DYN_IOINFO_SIZE. Non-WIN32_DYN_IOINFO_SIZE mode is simply more
efficient.
For future compatibility concerns, 3 forms of protection are offered.
If __pioinfo isn't exported anymore, the Perl build will break. In
WIN32_DYN_IOINFO_SIZE mode, if __pioinfo isn't heap memory anymore or the
start of a memory block, the runtime panic will happen. In with and without
WIN32_DYN_IOINFO_SIZE, only on a DEBUGGING build, the handle returned by
CRT's _get_osfhandle, which is the authentic handle in the CRT, is compared
to the handle found by accessing the ioinfo struct directly. If they don't
match, the handle swapping code is broken and the assert fails.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a WinCE build. On the 2nd nmake run, using Makefile.ce, eventually calls
the Extensions target which calls make_ext.pl. What happens is nmake for CE
for each module is called on the Desktop per module makefile from the
earlier Desktop build. Since the Desktop Perl already was built
sucessfully, all rules/deps are met in the Desktop per module makefile, and
nothing happens during the module building phase for a CE build. Previously
I used external file management tools to delete the per module Makefiles
before running Makefile.ce.
*make_ext.pl
- implement deleting and rebuilding the per module makefile on a Cross
build
- use constants for constant folding, there are opportunities for other
variables to be converted to constants in the future
- fix a bug from commit baff067e71 where unlink() on a file with an open
handle ($mfh) didn't delete the file from disk and a new per module
makefile would be not be built by make_ext.pl later since the per module
makefile was still on disk. This was observed on Win32. Also harden the
unlink code with a new _unlink sub that is fatal if the file is still on
disk after unlink supposedly deleted it.
- var $header and the quotemeta is because of an issue in Perl #119793
*Makefile.ce
- bring the debugging symbol generation flags and optimization flags
to be closer to a Dekstop VC Perl build
- ICWD is obsolete as of commit f6b3c354c9 , remove it
- MINIMOD is obsolete as of commit 7b4d95f74b , remove it
- make a poisoned config.h so if there is a XS building mixup between
a desktop and CE perl, the poisoned config.h for CE will stop the build
gracefully
- $(MINIPERL) has never been defined in Makefile.ce from day 1 (10 years)
replace with $(HPERL) everywhere, this was causing things to not run
silently since $(MINIPERL) was empty string. Use HPERL instead of
MINIPERL to allow flexibility to use the full perl binary if necessery
one day
- better cleaning on root makefile clean target
*win32/win32.h
*win32/win32iop.h
- silence alot of redefinition warnings which gave pages of warnings on
each WinCE compliand
*mg.c
- win32_get_errno is only on WIN32 build not WINCE
a "nmake -f Makefile.ce all" will now build the CE interp and all modules
in 1 shot with no user intervention
|
| |
|
|
|
|
|
| |
This simplifies some of the logic necessary for coping with its various
problems.
Suggested by Nicholas Clark.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since perl previously assigned WSAExxx values to $! on Windows it is quite
possible that (Perl-level) user code may also manually make similar assignments,
which will now cause breakage if the value put in $! is subsequently compared to
Errno/POSIX constants because the latter are now the corresponding Exxx values
where possible.
An example of this is in Net::Ping::tcp_connect(), which does the following to
fetch a socket-level error code:
unpack("i", getsockopt($self->{"fh"}, SOL_SOCKET, SO_ERROR))
and assigns the result (a WSAExxx value such as 10061) to $! and then goes wrong
in the subsequent test (in ping_tcp()) for $! == ECONNREFUSED (which is now 107
rather than 10061 if perl is built with VC10 or higher).
To avoid this we now intercept assignment to $! and convert any WSAExxx values
to Exxx values first. This causes a minor oddity in that this:
perl -le "$! = 10061; print 0+$!"
will now output 107 (for VC10+ perls) but this is surely preferable to the
alternative breakage described above.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Slim down the image and speed up start up time for Win32 miniperl by
removing Winsock. Also if the build process on Win32 in the future
requires sockets, commenting one line in win32.h will turn sockets back on
for miniperl, but this time with delay loading on VC Perl. The only casulty
of no sockets for Win32 miniperl was figuring out the computer's name in
win32/config_sh.PL. A workaround by using an ENV var was implemented. The
purpose of this commit is to speed up the build process of Perl.
As said in the comment in win32.h, the WIN32_NO_SOCKETS macro is
incomplete in implementation. It is only removed winsock from being linked
in in miniperl, not full Perl. PERL_IMPLICIT_SYS (specifically PerlSock in
win32/perlhost.h) and makedef.pl's hard coded list of win32_* function
exports cause winsock to still be linked in with even with
WIN32_NO_SOCKETS on full perl. Both PERL_IMPLICIT_SYS (win32/perlhost.h)
and makedef.pl would require changes to remove winsock from being linked
in on full perl in the future.
|
| |
|
|
|
|
|
| |
These assorted static allocated variables were in RW memory in the perl
image. Move them to RO memory so they are sharable between different
Perl processes by the OS. The lack of consting in Win32 Dynaloader traces
to commit 0a753a76406 . S_Internals_V traces to commit 4a5df386486 .
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
miniperl.exe does not load XS modules. It has no reason to export anything.
About 130 things are exported by VC Win32 miniperl. 90% of them are
the win32_* functions. All but a couple Perl_* exports are gone in the
exporting miniperl. See perl #115216 for the full list of accidentally
exported items. Also stop trying to find Win32CORE's boot function in
Perl_init_os_extras through the export table. It is not exported and not
in the miniperl image and GetProcAddress will never return not NULL. By
removing this GetProcAddress call, miniperl stops importing GetProcAddress
from kernel32 and a tiny bit startup time by miniperl during the full
perl build process. By removing the exports the compiler is free to use
more random (not cdecl) calling conventions and/or optimizing away code
than before. Also by removing the export entries, and the GetProcAddress
import, RO strings are removed from the miniperl image. This commit only
affects the VC miniperl. The Mingw miniperl remains unmodified except
for not trying to load Win32CORE through the export table and some of the
.c files being compiled with PERL_IS_MINIPERL when previously they were
not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In commit cdc4a174060 static noreturn function, on a C++ build, (specific
example, GCC ) got a post preprocessor prototype of
"extern "C" static void S_fn_doesnt_return(". GCC generates a compile error
if "extern "C"" and static used together. Plain C build were not affected.
This commit fixed the problem by creating 2 new static exclusive macros, so
extern "C" does not wind up on statics in a C++ build. The macros allow
enough flexibility so any compiler/platform that needs a noreturn
declaration specifier instead of a noreturn function attribute can have
one.
|
| |
|
|
|
|
|
| |
These are surely not required by anything, and are only stub functions
anyway so can easily be provided locally by anything that really does need
them. Also hide the declarations other than when building the core itself
as per the fix for [perl #114516].
|
| |
|
|
|
|
|
|
|
| |
The option is always defined by default and can't be disabled from the
makefiles. Manually disabling it causes several tests to fail, which
nobody has reported, so we presume nobody does this. The non-default
configuration is believed to be historical cruft with no value now, and
has clearly bitrotted in recent years (hence the test failures), so
remove it to simplify the codebase slightly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hide the perl.h declarations of gete?[ug]id and getlogin on Win32 since
they are already declared in win32/win32.h, nearer to their definitions
(stub functions for UNIX compatibility) in win32/win32.c.
Also only declare them, and kill(pg)?, sbrk, chown and mkstemp, under
PERL_CORE anyway since they are not exported: including declarations for
non-exported functions just hides compiler errors about the symbols being
undefined, which doesn't help when trying to fix subsequent errors from
the linker about the symbols being unresolved. (Actually, all but sbrk,
chown and mkstemp get indirected through the perlhost layer normally
anyway, but it doesn't hurt to still hide the declarations, and helps in
the case of PERL_IMPLICIT_SYS not being defined, where only kill is
redefined to something which is exported.)
The declarations of the set[ug]id stub functions remain for now because
those two symbols are currently exported.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
No idea why one of my previous commits added the bit. I blame
Cygwin git and the fact that t/porting/exec-bit.t is skipped
on Windows.
|
| |
|
|
|
|
|
| |
12a2785c7e86f586a05cad9ff90ce673c68c3115 only turned on MSVC noreturn for
external DLL XS modules, not inside the interp (perl5**.dll). This commit
fixes that. For me (bulk88), with an -O1 build, perl517.dll dropped
from 1044KB to 1036KB after applying this.
|
| |
|
|
|
|
|
|
| |
I thought I did test commit 12a2785c with VC6 and it built without
errors, but I can no longer reproduce this. Checking standard
CRT headers shows common usage (e.g. for longjmp() in setjmp.h) is
"__declspec(dllimport) __declspec(noreturn)", so let's use that
one instead.
|
| |
|
|
|
|
|
|
|
| |
This will reduce the machine code size on Visual C Perl, by removing C stack
clean up opcodes and possible jmp opcodes after croak() and similar
functions. Perl's existing __attribute__noreturn__ macro (and therefore
GCC's __attribute__((noreturn)) ) is fundamentally incompatible with MS's
implementation for noreturn functions. win32.h already has _MSC_VER
aware code blocks, so adding more isn't a problem.
|
| |
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perl traditionally stores WinSock error codes (values above 10000) in
errno, with corresponding support for $! to stringify them properly.
In Visual Studio 2010 (and presumably newer Windows SDKs) Microsoft
has started to define additional errno constants in errno.h (values
between 100 and 200) with conflicting names (e.g. EWOULDBLOCK).
There are 2 ways to deal with this situation:
1) Redefine the errno.h constants back to the winsock values for
the Errno and POSIX modules.
2) Translate the winsock error codes to the new errno constants
in the socket implementation in win32/win32sck.c.
Solution 1) has the advantage that any existing Perl code that has
numeric error codes hard-coded in it will continue to work.
Solution 2) has the advantage that XS code using external libaries can
set errno to the new constants, and they will be handled consistently
in the Perl core. It will however need additional support for other
compilers and runtime libraries that don't support these new error
codes.
This commit implements solution 1).
Blame attribution: the commit message is from Jan Dubois,
the actual patch was created by Steve Hay.
Signed-off-by: Jan Dubois <jand@activestate.com>
|
| |
|
|
|
|
|
| |
This is a refinement of commit 3aa0ac5aa. We still want to hang on
to the mapping between pseudo-process and thread handle, so that we
can still waitpid() after signalling SIGTERM. We just don't want to
wait implicitly on the signalled process anymore.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The code works around a bug in very old versions of MSVCRT.dll.
The issue has been fixed a long time ago by Microsoft, so anyone
who has installed a Windows Service Pack in the last 10 years
or so won't be affected by the problem.
|
| |
|
|
|
| |
Remove all supporting code for Windows 9x and Windows NT. The
minimum supported version is Windows 2000 now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes a difference for extensions that are "statically"
linked into the Perl library, like DynaLoader and Win32CORE.
The MinGW compiler/linker cannot resolve symbols that have
been annotated as "dllimport" but are actually defined inside
the same library.
An exception is needed for the ext/re extension, which
redefines core APIs internally, so these functions must
not be marked as "dllimport" either.
This commit is a fix/enhancement to commit ad6ab6c5.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By default C compilers will generate direct call instructions that the
linker will have to route trhough a call thunk if the call site is not
available at link time. By annotating all imported symbols the compiler
is able to generate a indirect call instruction directly.
This should improve performance minimally, but will also make sure the
Perl API functions have the same addresses inside the core and inside
XS modules. The ext/XS-APItest/t/call_checker.t tests rely on being able
to compare function addresses.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
| |
as we already know it, and use it in S_init_perllib() to save a strlen() in
S_incpush_use_sep().
|
