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.) --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=132955Thread Next