Perl problems

[Walter Roberson]

Some days I swear that I spend more time trying to install Perl and
Perl modules than I do actually -using- Perl

The below comments have to do with SGI IRIX 6.5.17f:


Does anyone have a fix for that darn Test::Harness "syntax error near *($w"
problem? I remember that I tracked it down once to the WFEXITED
macro of <sys/wait.h> -- the "real" wait status on IRIX is a structure
that fits within an int, but all the macros manipulate it as an int
with bit manipulation after doing *(int *)(w) . The (int *) is being
removed when perl converts the header, leaving *($w) which of course
perl doesn't like. But now I can't seem to find the location anymore to
even hack around it...

Does anyone have a fix for those prototyping warnings about _MIPS_* ?
I did find one CORE file that had them, but hacking that didn't
solve the problem.

How about a fix so that threaded perl will test properly? Okay,
so it's a "known problem" -- does that mean a problem with
IRIX's implimentation of pthreads, or does that mean a problem with
perl 5.6.1's implimentation of threads?

Or perhaps someone has a fix for all those modules that build and
test just fine but somehow the record of which version is installed
doesn't get updated so the CPAN module always thinks they need updating?

Or does someone have a Perl6 for IRIX? I see from google archives that
-someone- has been submitting bug reports about Perl6 on IRIX, but
it doesn't build for me...

Meanwhile, the perl supplied with IRIX is 5.004 which is old enough
now that a lot of the modules aren't supplied for it. And
SGI's 'nsadmin' program is built around perl, and complains about
things being missing or out of date. When I try to update them,
I get the problem lots of people have gotten over the years, about
no method 'new' existing for the module used to load in new modules.
Haven't found a posted solution for that one yet

Speaking of unavailable modules: I'm seeing now a bunch of modules
in CPAN that require 5.6.2 or later; the SGI freeware is 5.6.1
and I haven't managed to get 5.6.2 to build.

Then there's the problems in the date.t test for Template::Toolkit
where it offers the unhelpful message that "%s isn't numeric in eq".
Checking this one out, I see an attempt to use %s as a date format,
but %s isn't a valid date format as far as IRIX is concerned.
If I change to %S or anything else, I get messages about 11 not
matching the expected template... haven't figured out where the 11
comes from, as the next line seems to be asking for the name of
a weekday as the match.

XML::RSS...
t/version.............ok 1/6Use of uninitialized value in concatenation (.) or string at t/version.t line 14.


and so on, and so forth

 

[Tassilo v. Parseval]

Also sprach Walter Roberson:

Some days I swear that I spend more time trying to install Perl and
Perl modules than I do actually -using- Perl

The below comments have to do with SGI IRIX 6.5.17f:


Does anyone have a fix for that darn Test::Harness "syntax error near *($w"
problem? I remember that I tracked it down once to the WFEXITED
macro of <sys/wait.h> -- the "real" wait status on IRIX is a structure
that fits within an int, but all the macros manipulate it as an int
with bit manipulation after doing *(int *)(w) . The (int *) is being
removed when perl converts the header, leaving *($w) which of course
perl doesn't like. But now I can't seem to find the location anymore to
even hack around it...

I don't see how a C header would correlate with Test::Harness in any
way. Therefore the above doesn't make much sense to me.

[...]

And the rest isn't much clearer either, I am afraid.

What happens when you try to compile a recent Perl (either 5.6.2 or
5.8.2) on the machine in question? Will that work? If not, then you
should address your worries to the perl-porters using the perlbug
program. If you have in fact no functioning perl lying around, then send
a mail directly to (e-mail address removed). In either way, you should
tidy up your report a little so that people actually understand what you
are talking about.

Then there's the problems in the date.t test for Template::Toolkit
where it offers the unhelpful message that "%s isn't numeric in eq".
Checking this one out, I see an attempt to use %s as a date format,
but %s isn't a valid date format as far as IRIX is concerned.
If I change to %S or anything else, I get messages about 11 not
matching the expected template... haven't figured out where the 11
comes from, as the next line seems to be asking for the name of
a weekday as the match.

XML::RSS...
t/version.............ok 1/6Use of uninitialized value in concatenation (.) or string at t/version.t line 14.

Neither Template::Toolkit nor XML::RSS are part of a Perl core
distribution. Therefore, any reports have to go to the maintainers of
the respective packages and not the perl-porters.

Tassilo

 

[Walter Roberson]

:What happens when you try to compile a recent Perl (either 5.6.2 or
:5.8.2) on the machine in question? Will that work?

Doesn't even untar

lib/unicode/Is/DCwide.pl: File name too long
Cannot access lib/unicode/Is/DecoCanon.pl
mpeix/mpeixish.h: No such file or directory
[...]
xsutils.c: No such file or directory

THIS PACKAGE SEEMS TO BE INCOMPLETE.

Ah, this time I noticed that when the tar started, it had valid
names. I'll see if I can figure out whether the problem is with the
tar file being corrupt or with the tar file being too big to be
handled normally.


:In either way, you should
:tidy up your report a little so that people actually understand what you
:are talking about.

Anyone who has done much perl work on IRIX will have encountered
most of these problems time and time again, and either will have
a solution or won't. No point in my writing up complete bug reports
until I know that there are no quick solutions.

When I do write up bug reports, I write very thorough bug reports after
having done a lot of research to attempt to solve the problem myself --
and I write a fair number of bug reports. But that takes a long time,
and the number of problems I encounter with perl and perl modules is
substantial. I have already spent weeks (distributed over time) in
trying to track some of these problems, burned a lot of evenings and
weekends attempting to get the software working. Makes me reluctant
to spend my evening writing down exact symptoms and tests done
when anyone who already had a fix for IRIX would recognize a short
description. [Particularily since my SO will be decidedly unpleased
if I don't do the dishes soon!]

 

[Walter Roberson]

:Some days I swear that I spend more time trying to install Perl and
erl modules than I do actually -using- Perl

:The below comments have to do with SGI IRIX 6.5.17f:

Ah, I just noticed that I posted to comp.lang.perl.misc with
the very generic title 'Perl problems'. Sorry, I should have been
more specific. comp.lang.perl.misc was a last-minute addition
to the newsgroup list; when I constructed the Subject, I was only
planning to post to IRIX newsgroups.

 

[Walter Roberson]

:> The below comments have to do with SGI IRIX 6.5.17f:

:> Does anyone have a fix for that darn Test::Harness "syntax error near *($w"
:> problem? I remember that I tracked it down once to the WFEXITED
:> macro of <sys/wait.h>

:I don't see how a C header would correlate with Test::Harness in any
:way. Therefore the above doesn't make much sense to me.

Test::Harness has to be able to catch failed processes and
determine their exit status so that tests can continue cleanly.
It therefore needs to analyze system exit statuses. The exact
representation of system exit statuses is, though, not specified
by any standard: instead POSIX specifies the essential functionality
in terms of macros applied to a system exit status.

As the macros might vary from system to system, when perl is built,
it has to try to determine the appropriate macro from the system include
files. I recall that I have seen that happen during a build, but
I do not build perl often enough to know the exact mechanism used.
On a number of Unices, the underlying status is integral (usually
an 'int'), but on IRIX the underlying status is a union that the
macros do type-punning on in before applying arithmetic manipulation.
That type punning is unexpected by the perl conversion process
and it ends up creating code that has *($w) in it. As I recall,
about 1 1/2 years ago, I hacked the IRIX <sys/wait.h> to not do the
type punning if perl was being compiled, and rebuilt perl, and
that fixed the problem for that release.

Test::Harness is not the only affected module, but it is perhaps
the single most noticable module, as it is used for testing so many
other modules.

I hope this clarifies how a C header "correlates" with Test::Harness ?

As I recall, in order to track this problem down, I ended up building
a non-optimized version of perl with complete symbol table, and
using a debugger to trace through perl going through the layers of
doing a test -- it was the easiest way I could find at the time
to debug through layers of 'eval'.

 

[Walter Roberson]

|In article <[email protected]>,
|:Also sprach Walter Roberson:

|:What happens when you try to compile a recent Perl (either 5.6.2 or
|:5.8.2) on the machine in question? Will that work?

|Doesn't even untar

| THIS PACKAGE SEEMS TO BE INCOMPLETE.

|Ah, this time I noticed that when the tar started, it had valid
|names. I'll see if I can figure out whether the problem is with the
|tar file being corrupt or with the tar file being too big to be
|handled normally.

Still a bit of a mystery. The problems were exactly the same
whenever I loaded 5.8.2 via cpan, but when I fetched 5.8.2 from
the cpan ftp site, it came down fine, and had a -much- shorter list
of files to extract. I'm building the manually-loaded 5.8.2 now
and it seems to be going okay -- I'm through 'make test' without
problem and it's working on 'make install' now.

Perhaps the mirror near me (literally across the road ;-) )
has a corrupted copy.

 

[Walter Roberson]

:And the rest isn't much clearer either, I am afraid.

Well, an example, then, of a case in which a module version number
does not update after installation:

Running install for module if
Running make for I/IL/ILYAZ/modules/if-0.0401.tar.gz
Is already unwrapped into directory /applications/packages/perls/build/if-0.0401
Has already been processed within this session
Running make test
Prepending /applications/packages/perls/build/if-0.0401/blib/arch /applications/packages/perls/build/if-0.0401/blib/lib to PERL5LIB.
PERL_DL_NONLAZY=1 /usr/freeware/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t

t/if....ok
All tests successful.
Files=1, Tests=5, 0 wallclock secs ( 0.01 cusr + 0.03 csys = 0.04 CPU)
/sbin/make test -- OK
Running make install
Already done

cpan> r

Package namespace installed latest in CPAN file
AnyDBM_File undef 1.00 N/NW/NWCLARK/perl-5.8.2.tar.gz
Math::BigFloat 0.02 1.42 T/TE/TELS/math/Math-BigInt-1.68.tar.gz
if 0.03 0.0401 I/IL/ILYAZ/modules/if-0.0401.tar.gz


Thus I've just installed I/IL/ILYAZ/modules/if-0.0401.tar.gz
but cpan's 'r' thinks I'm still using 0.03 .

My experience is that the number of these problems increases over
time. I don't believe I have ever seen one of these problems
go away upon installing a yet newer version, but it is possible
that I failed to notice an instance of it fixing itself.

 

[Tassilo v. Parseval]

Also sprach Walter Roberson:

|In article <[email protected]>,
|:Also sprach Walter Roberson:

|:What happens when you try to compile a recent Perl (either 5.6.2 or
|:5.8.2) on the machine in question? Will that work?

|Doesn't even untar

| THIS PACKAGE SEEMS TO BE INCOMPLETE.

|Ah, this time I noticed that when the tar started, it had valid
|names. I'll see if I can figure out whether the problem is with the
|tar file being corrupt or with the tar file being too big to be
|handled normally.

Still a bit of a mystery. The problems were exactly the same
whenever I loaded 5.8.2 via cpan, but when I fetched 5.8.2 from
the cpan ftp site, it came down fine, and had a -much- shorter list
of files to extract. I'm building the manually-loaded 5.8.2 now
and it seems to be going okay -- I'm through 'make test' without
problem and it's working on 'make install' now.

Perhaps the mirror near me (literally across the road ;-) )
has a corrupted copy.

Possibly. It's a pity that there aren't yet any checksums on the CPAN
for the packages. Theoretically, an admin of a mirror could distribute
modified packages instead of the original ones from the major CPAN site.

Tassilo

 

[Tassilo v. Parseval]

Also sprach Walter Roberson:

:And the rest isn't much clearer either, I am afraid.

Well, an example, then, of a case in which a module version number
does not update after installation:

Running install for module if
Running make for I/IL/ILYAZ/modules/if-0.0401.tar.gz
Is already unwrapped into directory /applications/packages/perls/build/if-0.0401
Has already been processed within this session
Running make test
Prepending /applications/packages/perls/build/if-0.0401/blib/arch /applications/packages/perls/build/if-0.0401/blib/lib to PERL5LIB.
PERL_DL_NONLAZY=1 /usr/freeware/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t

t/if....ok
All tests successful.
Files=1, Tests=5, 0 wallclock secs ( 0.01 cusr + 0.03 csys = 0.04 CPU)
/sbin/make test -- OK
Running make install
Already done

cpan> r

Package namespace installed latest in CPAN file
AnyDBM_File undef 1.00 N/NW/NWCLARK/perl-5.8.2.tar.gz
Math::BigFloat 0.02 1.42 T/TE/TELS/math/Math-BigInt-1.68.tar.gz
if 0.03 0.0401 I/IL/ILYAZ/modules/if-0.0401.tar.gz


Thus I've just installed I/IL/ILYAZ/modules/if-0.0401.tar.gz
but cpan's 'r' thinks I'm still using 0.03 .

Is just CPAN.pm reporting the older version? What does

/usr/freeware/bin/perl -Mif -e 'print $if::VERSION'

say?

Another thing interesting to know might be whether this happens with any
new version of a module you install or just with 'if'. I noticed that
there seem to be problems with a package that is identical to a Perl
keyword:

ethan@ethan:~$ perl -Mif -e 'print if->VERSION'
syntax error at -e line 1, next token ???
Execution of -e aborted due to compilation errors.

This shouldn't happen and it could be somewhat connected to CPAN.pm not
recognizing the newer version (my CPAN.pm does it properly, though).

Have you tried upgrading CPAN.pm? It's one of those modules that I
always keep up-to-date.

Tassilo

 

[Walter Roberson]

|> Thus I've just installed I/IL/ILYAZ/modules/if-0.0401.tar.gz
|> but cpan's 'r' thinks I'm still using 0.03 .

|Is just CPAN.pm reporting the older version? What does

| /usr/freeware/bin/perl -Mif -e 'print $if::VERSION'

|say?

Good question. The VERSION comes out as 03 which is the old
version number.

:Another thing interesting to know might be whether this happens with any
:new version of a module you install or just with 'if'.

'if' was the example I had handy. I have seen the same thing with
a number of others that are not reserved words, such as some of
the Pod:: modules.

:Have you tried upgrading CPAN.pm? It's one of those modules that I
:always keep up-to-date.

Thanks, yes, I always update CPAN when I see a new version.

I did chase one of the modules I was having this issue with, before,
and it looked to me at the time as if the new version of the module
continued to use the old version time in the source. I did not
generalize on that, though, as I was not certain that I had found the
version information in the code I was looking at.

 

[Walter Roberson]

%In article <[email protected]>,
%|In article <[email protected]>,
%|:Also sprach Walter Roberson:

%|:What happens when you try to compile a recent Perl (either 5.6.2 or
%|:5.8.2) on the machine in question? Will that work?

%|Doesn't even untar

%| THIS PACKAGE SEEMS TO BE INCOMPLETE.

%Perhaps the mirror near me (literally across the road ;-) )
%has a corrupted copy.

Odd... when I used CPAN to try to load 5.6.2 or 5.8.2,
I'd get problems in unpacking the tar, but if I ftp the tar
from the same location then I have no problem unpacking it.

I've now successfully built 5.6.2, tested, and installed 5.6.2
and 5.8.2 on IRIX, including building 5.8.2 with threads,
and building 5.6.2 to use the shared perl lib. I had had a lot
of trouble with both before.