Perl problems

Discussion in 'Perl Misc' started by Walter Roberson, Jan 4, 2004.

  1. 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 :(
    --
    I don't know if there's destiny,
    but there's a decision! -- Wim Wenders (WoD)
     
    Walter Roberson, Jan 4, 2004
    #1
    1. Advertising

  2. 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 . 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
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
     
    Tassilo v. Parseval, Jan 4, 2004
    #2
    1. Advertising

  3. In article <bta3l7$gmn$-Aachen.DE>,
    Tassilo v. Parseval <-aachen.de> wrote:
    :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

    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!]

    --
    WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,vonNeumann}D ?
     
    Walter Roberson, Jan 4, 2004
    #3
  4. IRIX Perl Problems [was Perl problems]

    In article <bta2tv$8rh$>,
    Walter Roberson <-cnrc.gc.ca> wrote:
    :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:

    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.
    --
    Positrons can be described as electrons traveling backwards in time.
    Certainly many Usenet arguments about the past become clearer when they
    are re-interpreted as uncertainty about the future.
    -- Walter Roberson
     
    Walter Roberson, Jan 4, 2004
    #4
  5. In article <bta3l7$gmn$-Aachen.DE>,
    Tassilo v. Parseval <-aachen.de> wrote:
    :Also sprach 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'.
    --
    The Knights Of The Lambda Calculus aren't dead --this is their normal form!
     
    Walter Roberson, Jan 5, 2004
    #5
  6. In article <bta61q$a5o$>,
    Walter Roberson <-cnrc.gc.ca> wrote:
    |In article <bta3l7$gmn$-Aachen.DE>,
    |Tassilo v. Parseval <-aachen.de> wrote:
    |: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.
    --
    "Infinity is like a stuffed walrus I can hold in the palm of my hand.
    Don't do anything with infinity you wouldn't do with a stuffed walrus."
    -- Dr. Fletcher, Va. Polytechnic Inst. and St. Univ.
     
    Walter Roberson, Jan 5, 2004
    #6
  7. In article <bta3l7$gmn$-Aachen.DE>,
    Tassilo v. Parseval <-aachen.de> wrote:
    :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.
    --
    Caution: A subset of the statements in this message may be
    tautologically true.
     
    Walter Roberson, Jan 5, 2004
    #7
  8. Also sprach Walter Roberson:

    > In article <bta61q$a5o$>,
    > Walter Roberson <-cnrc.gc.ca> wrote:
    >|In article <bta3l7$gmn$-Aachen.DE>,
    >|Tassilo v. Parseval <-aachen.de> wrote:
    >|: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
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
     
    Tassilo v. Parseval, Jan 5, 2004
    #8
  9. Also sprach Walter Roberson:

    > In article <bta3l7$gmn$-Aachen.DE>,
    > Tassilo v. Parseval <-aachen.de> wrote:
    >: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
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
     
    Tassilo v. Parseval, Jan 5, 2004
    #9
  10. In article <btbbtm$duk$-Aachen.DE>,
    Tassilo v. Parseval <-aachen.de> wrote:
    |Also sprach 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.
    --
    *We* are now the times. -- Wim Wenders (WoD)
     
    Walter Roberson, Jan 5, 2004
    #10
  11. In article <btadr7$dht$>,
    Walter Roberson <-cnrc.gc.ca> wrote:
    %In article <bta61q$a5o$>,
    %Walter Roberson <-cnrc.gc.ca> wrote:
    %|In article <bta3l7$gmn$-Aachen.DE>,
    %|Tassilo v. Parseval <-aachen.de> wrote:
    %|: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.
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare. -- Blair Houghton.
     
    Walter Roberson, Jan 6, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dpackwood
    Replies:
    3
    Views:
    1,830
  2. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Jan 23, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    313
    PerlFAQ Server
    Jan 23, 2011
  3. PerlFAQ Server
    Replies:
    0
    Views:
    705
    PerlFAQ Server
    Feb 3, 2011
  4. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Feb 27, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    308
    PerlFAQ Server
    Feb 27, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    709
    PerlFAQ Server
    Apr 4, 2011
Loading...

Share This Page