Re: Bizarre copy of unknown
On Jan 9, 2013, at 11:01 AM, Thomas Pfau tfp...@gmail.com wrote: I went back to the threaded perl and removed the CCFLAGS from makefile.pl. It builds and runs now. I'm not sure why that was in there. It must have been added by an older version of h2xs. Thanks for the help. Sorry for distracting you from other things. Glad I could help. And VMS::CMS looks like a nifty module :-). Craig A. Berry mailto:craigbe...@mac.com ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: Bizarre copy of unknown
On Jan 8, 2013, at 10:07 PM, Thomas Pfau tfp...@gmail.com wrote:
Bizarre copy of UNKNOWN in list assignment at
/DISK$USERS/PFAU/PROG/PERL/vms-cms/blib/lib/VMS/CMS.pm line 490.
A quick web search shows that this usually means the compiler flags used to
compile the extension are different from the compiler flags used to compile
Perl. Your Makefile.PL has the line:
CCFLAGS =
/include=[]/standard=relaxed_ansi/prefix=all/obj=.obj/noshare_globals
which will be similar but not 100% the same as what's used to build Perl,
depending on configuration. You'll probably want to take $Config{ccflags} and
append /noshare_globals to it, though since that's the default for the
compiler, it doesn't seem necessary to specify it.
You can see what your Perl was built with by doing:
$ perl -V:ccflags
ccflags='/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj
/NOANSI_ALIAS/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=_USE_STD_STAT=1';
Craig A. Berry
mailto:craigbe...@mac.com
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
Re: Bizarre copy of unknown
I think this has something to do with threads. I rebuilt perl at work
without threads and the module works again.
On Jan 9, 2013 8:20 AM, Craig A. Berry craigbe...@mac.com wrote:
On Jan 8, 2013, at 10:07 PM, Thomas Pfau tfp...@gmail.com wrote:
Bizarre copy of UNKNOWN in list assignment at
/DISK$USERS/PFAU/PROG/PERL/vms-cms/blib/lib/VMS/CMS.pm line 490.
A quick web search shows that this usually means the compiler flags used
to compile the extension are different from the compiler flags used to
compile Perl. Your Makefile.PL has the line:
CCFLAGS =
/include=[]/standard=relaxed_ansi/prefix=all/obj=.obj/noshare_globals
which will be similar but not 100% the same as what's used to build Perl,
depending on configuration. You'll probably want to take $Config{ccflags}
and append /noshare_globals to it, though since that's the default for
the compiler, it doesn't seem necessary to specify it.
You can see what your Perl was built with by doing:
$ perl -V:ccflags
ccflags='/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj
/NOANSI_ALIAS/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=_USE_STD_STAT=1';
Craig A. Berry
mailto:craigbe...@mac.com
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
Bizarre copy of unknown
I am having issues with my 5.16.2 build. Modules that worked fine on 5.8 and 5.10 are now aborting with this error when returning an undefined value by referencing PL_sv_undef. I have been fixing these by changing them to sv_newmortal() but I question why this code is suddenly broken. Does anyone know what changed?
Re: Bizarre copy of unknown
This is even causing problems with the generated constant function. If I try to get the value of a constant I get this: $x = VMS::CMS::CMS_K_ACCEPT Bizarre copy of UNKNOWN in list assignment at /DISK$USERS/PFAU/PROG/PERL/vms-cms/blib/lib/VMS/CMS.pm line 490. That implies that the code created by ExtUtils::MakeMaker::WriteConstants is broken. On Tue, Jan 8, 2013 at 10:59 AM, Thomas Pfau tfp...@gmail.com wrote: I am having issues with my 5.16.2 build. Modules that worked fine on 5.8 and 5.10 are now aborting with this error when returning an undefined value by referencing PL_sv_undef. I have been fixing these by changing them to sv_newmortal() but I question why this code is suddenly broken. Does anyone know what changed? -- Thomas Pfau tfp...@gmail.com http://www.linkedin.com/in/thomaspfau http://nbpfaus.net/~pfau/
Re: Bizarre copy of unknown
On Tue, Jan 8, 2013 at 11:02 PM, Craig A. Berry craigbe...@mac.com wrote: On Jan 8, 2013, at 9:14 PM, Thomas Pfau tfp...@gmail.com wrote: It looks like the definition of PL_sv_undef has something to do with threads. Could this be broken because I enabled threads in my build? It doesn't have anything to do with threads directly, except all PL_xxx global variables are not really global variables under threads, but are instead members of the interpreter struct. On Tue, Jan 8, 2013 at 9:24 PM, Thomas Pfau tfp...@gmail.com wrote: This is even causing problems with the generated constant function. If I try to get the value of a constant I get this: $x = VMS::CMS::CMS_K_ACCEPT The ampersand is forcing it to be interpreted as a subroutine call, but that's not really a subroutine is it? Yes. References to constants are resolved using AUTOLOAD which treats it like a subroutine. The subroutine returns the value of the constant. Bizarre copy of UNKNOWN in list assignment at /DISK$USERS/PFAU/PROG/PERL/vms-cms/blib/lib/VMS/CMS.pm line 490. The error message means it doesn't know the type of the scalar that's having its flags checked (search for Bizarre in sv.c). I see that most of your routines have return values of type SV *, so I would think that instead of RETVAL = PL_sv_undef; you would want: RETVAL = (SV *) PL_sv_undef; but I don't know if that would help with the immediate problem. I don't think that would help. RETVAL should be declared by the XS generation code as SV* so I don't think the cast would accomplish anything. I'll take a look at the generated C code. I haven't had time to download your module and try it. Is the one on CPAN the latest? Yes, the one on CPAN exhibits the problem. -- Thomas Pfau tfp...@gmail.com http://www.linkedin.com/in/thomaspfau http://nbpfaus.net/~pfau/
