Skip Menu |
Report information
Id: 1006
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: D.White [at] mcs.surrey.ac.uk
Cc:
AdminCc:

Operating System: unix
PatchStatus: (no value)
Severity: medium
Type: (no value)
Perl Version: (no value)
Fixed In: (no value)



To: perlbug [...] perl.com
Subject: Clean build of perl 5.003_03 on Solaris 2.7 (Sparc): test problems.
From: D.White [...] mcs.surrey.ac.uk
Cc: scs [...] jhereg.perl.com
Date: Fri, 16 Jul 1999 15:53:06 +0100
Download (untitled) / with headers
text/plain 3.7k
After doing a clean build of Perl 5.005_03 on Solaris 2.7 on a Sun SPARC Ultra Enterprise 450, running make test, I get two test failures. How do I know if this is expected? The first test error is: lib/dumper.........FAILED at test 52 I followed the instructions and looked at the tests individually. I cd'ed into t, and ran "./perl lib/dumper.t". That gave me a long test output, where as expected test 52 was the first (of several) that failed: not ok 52 --Expected-- #$foo = \*::foo; #*::foo = \5; #*::foo = [ # #0 # 10, # #1 # '', # #2 # { # 'a' => 1, # 'b' => '', # 'c' => [], # 'd' => {} # } # ]; #*::foo{ARRAY}->[1] = $foo; #*::foo{ARRAY}->[2]{'b'} = *::foo{SCALAR}; #*::foo{ARRAY}->[2]{'c'} = *::foo{ARRAY}; #*::foo{ARRAY}->[2]{'d'} = *::foo{ARRAY}->[2]; #*::foo = *::foo{ARRAY}->[2]; #@bar = @{*::foo{ARRAY}}; #%baz = %{*::foo{ARRAY}->[2]}; --Got-- #$foo = \*::foo; #*::foo = \5; #*::foo = [ # #0 # 10, # #1 # '', # #2 # { # 'a' => 1, # 'b' => '', # 'c' => [], # 'd' => {} # } # ]; #*::foo]] = $foo; #*::foo]]]{'b'} = *::foo¤; #*::foo]]]{'c'} = *::foouu; #*::foo]]]{'d'} = *::foo]]]; #*::foo = *::foo]]]; #@bar = @{*::foouu}; #%baz = %{*::foo]]]}; This does appear to be a genuine bug in Data::Dumper, doesn't it? - all those funny symbols and lines such as '*::foo{ARRAY}->[1] = $foo' being shown as '*::foo]] = $foo'! Has anyone seen this before? This is of course the Data:: Dumper module supplied as part of the perl kit.. Moving onto the second test failure: lib/ipc_sysv.......Constant subroutine redefined at ../lib/DynaLoader.pm line 65535. Constant subroutine redefined at ../lib/DynaLoader.pm line 65535. Constant subroutine redefined at ../lib/DynaLoader.pm line 65535. Constant subroutine redefined at ../lib/DynaLoader.pm line 65535. Constant subroutine redefined at ../lib/DynaLoader.pm line 65535. .... Undefined subroutine &IPC::SysV::IPC_PRIVATE called at lib/ipc_sysv.t2). line 56. FAILED at test 1 Running './perl lib/ipc_sysv.t' gave the same error messages (well, it would, wouldn't it, with an error that severe). I examined ../lib/IPC/SysV.pm, but I'm afraid I don't understand enough about the autoloader to determine what it is actually doing :-) I wondered if the problem was to do with h2ph (which I haven't run, and which comes later in your install instructions) - I noticed that the h2ph section said h2ph screws up on typecasts, and I couldn't help but note that the /usr/include/sys/ipc.h file has: #define IPC_PRIVATE (key_t)0 /* private key */ (This was true on Solaris 2.5.1 also....) Is that the problem? I ran the same tests on Perl 5.005_02, originally compiled on Solaris 2.5.1, and then moved lock stock and barrel to the 2.7 machine. Both dumper and ipc_sysv worked! Help? cheers, duncan ------------------------------------------------------------------------------ Duncan C. White, Senior Computing Officer, Dept of Computing, University of Surrey, Guildford, Surrey GU2 5XH, UK. Email: D.White@surrey.ac.uk Phone: +441 483 259632 URL: http://www.mcs.surrey.ac.uk/showstaff?D.White Fax: +441 483 259385 PGPkey: http://www.mcs.surrey.ac.uk/Personal/D.White/pgpkey.html Key fingerprint = 91 93 0D 90 D0 5E 62 BF 57 39 08 56 43 FC E5 C8 ------------------------------------------------------------------------------ "Perhaps this is the collective's new strategy - they don't assimilate anyone any more, they just stand around looking helpless." -- B'elanna Torres, Star Trek: Voyager episode "Drone" ------------------------------------------------------------------------------


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