Skip Menu |
Report information
Id: 123211
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: bulk88 <bulk88 [at] hotmail.com>
Cc:
AdminCc:

Operating System: mswin32
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.21.4
Fixed In: (no value)

Attachments


Subject: [PATCH] remove PERL_IMPLICIT_SYS stubs
To: perlbug [...] perl.org
From: bulk88 <bulk88 [...] hotmail.com>
Date: Fri, 14 Nov 2014 22:45:50 -0500
Download (untitled) / with headers
text/plain 4.3k
This is a bug report for perl from bulk88@hotmail.com, generated with the help of perlbug 1.40 running under perl 5.21.4. ----------------------------------------------------------------- [Please describe your issue here] See attached patch. This will break the Netware build and IDK what to do. I got no responses to http://www.nntp.perl.org/group/perl.perl5.porters/2014/11/msg222107.html [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.21.4: Configured by Owner at Thu Sep 18 12:08:58 2014. Summary of my perl5 (revision 5 version 21 subversion 4) configuration: Derived from: 7d2b2edb94ab56333b9049a3e26d15ea18445512 Ancestor: 19be3be6968e2337bcdfe480693fff795ecd1304 Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DPERL_HASH_FUNC_ONE_AT_A_TIME -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T', optimize='-O1 -MD -Zi -DNDEBUG', cppflags='-DWIN32' ccversion='12.00.8168', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8, longdblkind=0 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"c:\perl521\lib\CORE" -machine:x86' libpth=C:\PROGRA~1\MIAF9D~1\VC98\lib libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl521.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"c:\perl521\lib\CORE" -machine:x86' Locally applied patches: uncommitted-changes a0fe7a7e75de29e59f1da0d6822dc06e5be658fe a261faffee83d0145642ab5d1d046c9f813bc497 6506ab86ad1602a9ca720fcd30446dce1461d23d 7d2b2edb94ab56333b9049a3e26d15ea18445512 --- @INC for perl 5.21.4: lib C:/perl521/srcnew/lib . --- Environment for perl 5.21.4: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH= PERL_BADLANG (unset) PERL_JSON_BACKEND=Cpanel::JSON::XS PERL_YAML_BACKEND=YAML SHELL (unset)

Message body is not shown because it is too large.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 419b
On Fri Nov 14 19:47:37 2014, bulk88 wrote: Show quoted text
> See attached patch. This will break the Netware build and IDK what to > do. I got no responses to > http://www.nntp.perl.org/group/perl.perl5.porters/2014/11/msg222107.html
I don't think this type of change is acceptable. Second opinions welcome. I do wonder how difficult it would be to modify perl to be able to build with threads but without PERL_IMPLICIT_SYS. Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 282b
On Wed Nov 19 19:42:28 2014, tonyc wrote: Show quoted text
> I do wonder how difficult it would be to modify perl to be able to > build with threads but without PERL_IMPLICIT_SYS. > > Tony
Turn off USE_IMP_SYS in the Win32 makefiles. The option already exists. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 753b
On Wed Nov 19 23:55:16 2014, bulk88 wrote: Show quoted text
> On Wed Nov 19 19:42:28 2014, tonyc wrote:
> > I do wonder how difficult it would be to modify perl to be able to > > build with threads but without PERL_IMPLICIT_SYS. > > > > Tony
> > Turn off USE_IMP_SYS in the Win32 makefiles. The option already exists. >
Yes, indeed. This is how I always build perl since I've never had a need for what PERL_IMPLICIT_SYS gives you, and turning it off enables turning on PERL_MALLOC, which I've always found is generally better (at least, at the things that perl does) than the system malloc on Windows. A long-outstanding todo item on Windows is to enable building with PERL_MALLOC with PERL_IMPLICIT_SYS turned on, but I've never found the tuits to even look at it.
From: Tony Cook <tony [...] develop-help.com>
To: Steve Hay via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #123211] [PATCH] remove PERL_IMPLICIT_SYS stubs
Date: Thu, 20 Nov 2014 19:41:03 +1100
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 972b
On Thu, Nov 20, 2014 at 12:08:35AM -0800, Steve Hay via RT wrote: Show quoted text
> On Wed Nov 19 23:55:16 2014, bulk88 wrote:
> > On Wed Nov 19 19:42:28 2014, tonyc wrote:
> > > I do wonder how difficult it would be to modify perl to be able to > > > build with threads but without PERL_IMPLICIT_SYS. > > > > > > Tony
> > > > Turn off USE_IMP_SYS in the Win32 makefiles. The option already exists. > >
> > Yes, indeed. This is how I always build perl since I've never had a need for what PERL_IMPLICIT_SYS gives you, and turning it off enables turning on PERL_MALLOC, which I've always found is generally better (at least, at the things that perl does) than the system malloc on Windows. > > A long-outstanding todo item on Windows is to enable building with PERL_MALLOC with PERL_IMPLICIT_SYS turned on, but I've never found the tuits to even look at it.
Ok, my memory played tricks on me, I though it was required for threads, but it's only required for fork() emulation. Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.7k
On Wed Nov 19 19:42:28 2014, tonyc wrote: Show quoted text
> On Fri Nov 14 19:47:37 2014, bulk88 wrote:
> > See attached patch. This will break the Netware build and IDK what to > > do. I got no responses to > > http://www.nntp.perl.org/group/perl.perl5.porters/2014/11/msg222107.html
> > I don't think this type of change is acceptable. Second opinions > welcome.
To be clear, my objection is to: +/* The function pointer type puning works since these are __cdecl i386, + the register+__cdecl-ish calling convenstion on Win64 and WinCE on ARM + (but PERL_IMPLICIT_SYS isn't available on WinCE perl). So these casts are + like a variodic function ignoring its "..." args and never derefing them. + The "..." arg being ignored is "struct IPerlProc* piPerl". + If __stdcall or __fastcall on i386 was used here, this would crash */ +const static struct IPerlProc perlProc = +{ + (LPProcAbort)win32_abort, + (LPProcCrypt)win32_crypt, +/* GCC 4.6.3 cant/wont tailcall PerlProc*() to a "jmp" so use the non-dllimport + style import stubs instead of reling on GCC to optimize PerlProc*() to + a import stub */ +#ifndef _MSC_VER + (LPProcExit)exit, + (LPProc_Exit)_exit, + (LPProcExecl)execl, +#else /* since VC 2003 uses dllimport, a C++ style static initializer function + will fill these 3 struct members at startup, also it means "const" is + ignored and struct perlProc is placed in unshared RW memory, the + PerlProc*() functions may or may not optimize to just "jmp" but it is + better than a RW struct */ + (LPProcExit)win32_exit, + (LPProc_Exit)win32__exit, + (LPProcExecl)win32_execl, +#endif + + (LPProcExecv)win32_execvp, + (LPProcExecvp)win32_execvp, where the code is wedging a function with a different parameter list into a function pointer. Tony


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org