Front page | perl.perl5.porters |
Postings from April 2018
On Mon, Apr 23, 2018 at 05:59:21AM -0700, Steve Hay via RT wrote:
> On Fri, 20 Apr 2018 17:23:46 -0700, bulk88 wrote:
> > On Thu, 19 Apr 2018 23:08:56 -0700, bulk88 wrote:
> > > I still can't build C++ perl because of PL_nan wrong declaration by
> > > jhi
> > > https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548
> > > . The lvalue cast and C++11 postfix operator space issues were found
> > > by others, not me.
> >
> > I'm starting to think
> > https://perl5.git.perl.org/perl.git/commitdiff/0879cd66ef3f00918ae26d9bb7ac555d3911c548
> > needs to be reverted outright. PL_nan/PL_inf must be either const and
> > in globvar.sym or perlvars.h and RT inited. There are only 2 kinds of
> > global vars in perl API. PL_nan/PL_inf should match existing
> > infrastructure. Not special casing itself. Something about the jhi
> > vax-netbsd series of commits doesn't make sense. On a C++ build, why
> > does it matter if perl's core symbols are C mangled or C++ mangled by
> > the CC/LD, aslong as its all declared the same way in every .o? How
> > does the rest of globvar.sym global vars work with just EXTCONST (C++
> > sym name) but not "EXTERN_C const" on vax-netbsd platform? Is POSIX.xs
> > compiled in C mode even on a C++ perl or something with EUMM CFLAGS
> > changes? Is anyone but JHI able to compile perl for vax-netbsd?
>
> I asked Jarkko about that commit. He suggested reverting it, but double checking that the whole thing then still builds also for Linux using g++.
>
> Is anyone able to do that? (Presumably I could do it on dromedary, but wouldn't really know what I'm doing -- I've not built perl on anything UNIXy for many, many years.)
I'll have a look
--
All wight. I will give you one more chance. This time, I want to hear
no Wubens. No Weginalds. No Wudolf the wed-nosed weindeers.
-- Life of Brian
Thread Previous
|
Thread Next