in reply to Re: object version does not match
in thread object version does not match

Thank you Rob! I went on a safari for stray copies of B.pm on my system and found some strange things. The problem was caused by altering @INC with a use lib statement that exposed a folder that for some forgotten reason has an old copy of B.pm 1.68 renamed to b.pm. But this has been the case for years and it still works like that on my old box. I wonder why perl 5.26.2 on macos 10.13.4 ignores my local copy of B at b.pm but perl 5.38.2 on macos 14.3 tries to use it and gets confused? I also don't see why this doesn't bother apache or morbo in either case.

The other oddity is not directly related to this problem but involves the system perl on Apple's latest macos: sonoma. My hunt for B.pm revealed that although the system perl is 5.30.3 there is also a full set of core modules for perl 5.34 installed from the factory:

/System/Library/Perl/5.30/darwin-thread-multi-2level/B.pm
/System/Library/Perl/5.34/darwin-thread-multi-2level/B.pm
I guess they are planning an upgrade at some point... Thanks again!

www.cpan.org/ports/binaries.html#macos

Replies are listed 'Best First'.
Re^3: object version does not match
by syphilis (Archbishop) on May 10, 2024 at 01:46 UTC
    I wonder why perl 5.26.2 on macos 10.13.4 ignores my local copy of B at b.pm but perl 5.38.2 on macos 14.3 tries to use it and gets confused?

    I don't think that's actually happening.
    On a case-sensitive system (which yours is ?) "use B;" will not load b.pm because of the case mismatch.
    UPDATE: Hmmm ... apparently macos systems are typically case-insensitive, so I could be wrong there.

    Also, I think that 1.68 is the version that ships with perl-5.26.2, so it's more likely to be loading that B.pm .

    In addition to "use lib" directives, also check to see whether the PERL5LIB environment variable is pulling additional paths into @INC.
    Maybe it's set for your perl environment, but the apache environment doesn't see it.

    Anyway, you're on the right track.

    Cheers,
    Rob
      >> I wonder why perl 5.26.2 on macos 10.13.4 ignores my local copy of B at b.pm

      > I don't think that's actually happening.
      > On a case-sensitive system (which yours is ?) "use B;" will not load b.pm because of the case mismatch.

      You are right that 5.26.2 is not ignoring b.pm on my old system, but believe it or not it IS using b.pm, and since the version matched it worked. On my new box 5.38.2 was also trying to use b.pm so I renamed it and the problem evaporated. I'm not using apache on the new box yet, even though macs come with 2.4.56 included, but morbo is not bothered by b.pm for some reason.

      I don't know why but on macOS you can type perldoc data::dumper and it will work, but on Linux you must spell it Data::Dumper. You can also use lowercase module names when using them in one liners for OO modules, but to call functions you must use the proper case:

      perl -Mdata::dumper -we'$d=Data::Dumper->new(\@ARGV);print$d->Dump' fo +o bar
      $VAR1 = 'foo';
      $VAR2 = 'bar';
      perl -Mdata::dumper -we'print Dumper(\@ARGV)' foo bar
      Undefined subroutine &main::Dumper called at -e line 1.
        I don't know why but on macOS you can type perldoc data::dumper and it will work, but on Linux you must spell it Data::Dumper

        Or simply use the -i flag as intended:

        $ perl -E 'say $^O' linux $ perldoc -i data::dumper | head NAME Data::Dumper - stringified perl data structures, suitable for both printing and "eval" SYNOPSIS use Data::Dumper; # simple procedural interface print Dumper($foo, $bar); $

        🦛