develooper Front page | perl.perl5.porters | Postings from July 2016

[perl #128438] [Win32] 5.25.2 fails to build in ListUtil.xs

Thread Previous
Tony Cook via RT
July 28, 2016 04:47
[perl #128438] [Win32] 5.25.2 fails to build in ListUtil.xs
Message ID:
On Thu Jul 14 09:53:22 2016, bulk88 wrote:
> On Wed Jul 13 21:59:53 2016, tonyc wrote:
> > On Wed Jun 22 23:58:55 2016, bulk88 wrote:
> > > The core patch is unnecessary, I already submitted a patch to SLU
> > > that
> > > makes it ppport free
> >
> > The problem is this makes Win32 an even more special snowflake than
> > it
> > needs to be - making it harder for CPAN upstream authors to maintain
> > their modules.
> >
> > An alternative to my original patch is to clean up the differences
> > between the real-ppport.h and empty-ppport.h environments by adding
> > PERL_BCDVERSION to perl.h, as per the attached patch.
> >
> > Tony
> I dont remember the default include order for EUMM .c files, but
> wouldn't first perl.h be included from installed CORE dir, then in the
> .xs/.c, ppport.h is included, but the local tarballed ppport.h is
> picked over the CORE one (
> us/library/36k2cdd4.aspx ) because all CPAN modules that use ppport.h
> are supposed to ship their own copy of it, which might be a very new
> ppport.h or very old ppport.h?
> Im thinking there will still be redefinition warnings between blead
> perl.h and old ppport.h'es since old ppport.h'es wont have the ifndef

I tested a CPAN XS module with ppport.h against the modified build
with no errors and no warnings.  It was however MSVC.

A compiler *should* accept the redefinition which will occur between
perl.h and an older ppport.h, since redefining a macro with the same
sequence of tokens is explicitly legal in C89, C99 and C11.

That said, there is a risk that a compiler will produce noise on such
a redefinition, which makes my second patch less suitable.

> For a cpan module to be in core, it already has special requirements
> for its build process. It can't require XS code.

Why not?  We can add dependencies between XS modules.

> It can't require an
> SQL server or 3rd party libs.

GDBM_File, DB_File depend on 3rd party libs.

> It can't require root or a package
> manager (Alien cough cough). Continuing to ban ppport.h in core makes
> sense since many modules already do it with USE_PPPORT_H/_NOT_CORE, so
> its not a special snowflake scenario. Simplifying the module
> dependency tree is also good for all OSes to increase parallelism or
> decrease the number of serial building points (bulk88 wont touch the
> unix makefile, so bulk88 will never fix the false
> Math::BigInt::FastCalc dep on List::Utils, this is from the IRC convo
> yesterday in #p5p).
> Here is an idea, Im not 100% sure it is worthwhile to pursue. Im
> thinking maybe the empty ppport.h should contain a "#error ppport.h
> not available in core" instead of being empty. Greping /cpan shows all
> modules except two guard against using ppport.h on blead with either
> USE_PPPORT_H or _NOT_CORE macros. IPC-SysV and Win32API-File needs to
> be fixed. Pathtools and Time::HiRes in /dist also need fixing. There
> are only 5 modules listed, one is SLU, in
> . Getting
> it to zero doesn't seem impossible. Then makeppport target from the
> root makefiles, mkppport file and mkppport.lst file can be deleted
> forever. Im not 100% sure putting a #error will solve anything,
> because just adding USE_PPPORT_H or _NOT_CORE isn't a 100% guarantee
> that the .xs file uses a ppport-only macro. Only looking at the code
> throughly might show or make it standout that it used a ppport-only
> macro. Also at a random point in the build, the #error ppport.h will
> become the full ppport.h and it wont error anymore, covering up core
> modules that use ppport.h when they shouldn't.

That might be a future change.

> The "empty ppport.h design" already went through one round of "fix the
> module" last year with

Yes, I remember that.

The issues raised and fixed while you did that work to make dmake
(which fed into the gmake changes) make me less happy to stay with the
empty ppport.h on Win32 [gd]make.

> Unless p5p changes blead perl to NEVER install the full ppport.h in
> installed CORE dir and if a CPAN on CPAN module does #include
> "ppport.h", and didn't ship its own copy of ppport.h in its tarball,
> someone can say its the module author's fault for relying on the
> user's existing installed, random age, possibly medieval ppport.h. IDK
> if this is true/right/opinions/etc.

That's only an issue if the compiler fails to build because of the redefinition, if it does fail to build it's not a C compiler.

I've applied my original patch that re-instates building ppport.h as


via perlbug:  queue: perl5 status: open

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About