in reply to Re: Calling an XSUB method from Catalyst
in thread Calling an XSUB method from Catalyst

Thank you for your reply

I'm not sure that it is a permissions issue. I'll be delighted if I am wrong though!

I installed it using the Makefile rule make install_site having run perl Makefile.PL. I did adjust the output directories to exist in a known place in an SVN repository off my home directory - this was deliberate as the people working on this do not all have root access on their respective machines. The location is correctly given to perl in the -I argument. Removing the -I prevents the code from running at all, where as including it satisfies the interpreter, until the function is called.

The permissions on the .so are 555. and the .ix and .bs are 444. I'm not sure what the purpose of the .ix and .bs are though.

Everything else is a mix of 444 and 644 for the files; all of the directories are 755. Everything is owned by me:me all the way up and down the directory tree (until I get to /home).

Thank you again for your time

Replies are listed 'Best First'.
Re^3: Calling an XSUB method from Catalyst
by Anonymous Monk on Jun 03, 2009 at 08:44 UTC
    So the use statement in the catalyst program succeeds? Then its your code. You did somethingcatalyst->foo but you wanted myfooxswbar->foo.
[reply]
[d/l]
[select]

      Thank you for your reply.

      Both use and require seem to find the package, but the method cannot be called. Therefore, it is entirely possible that I am in the wrong name-space: although I specify the module explicitly. I have engineered a relevant snippet for perusal:

      package Catalyst::View::Foo;
use base 'Catalyst::View';
use Bar qw/my_method/;
use Data::Dumper;

###
# Method of interest
#
sub process {
  eval {
    Bar::my_method(1,2,3); # results in ``Undefined subroutine &Bar::my_method''
  }
  print Dumper $!, $?, $@; # very lazy error-finder
}

1;

      I suppose it could be that it doesn't like calling non-OO perl (well, technically perl and xsub) ... although print Dumper works so I'm not sure that this analysis is correct.

      I'm really stumped on this on this. What Jettero posted earlier prompted me to check whether %ENV was being truncated in some way by catalyst, but catalyst %ENV appears to contain only additional information to when checked against the command-line perl %ENV (Thanks for the prompt, Jettero :) ).

      I'm still hoping that I've done something really silly and obvious :)

      Rather than trusting that I have got the correct options to perl, I have now installed it into my machine properly, in the hope that it would have resolved any path issues not finding the .so. Unfortunately, there has been no change in outcome, although it can be called correctly from the command-line script anywhere in my directory tree, which has reduced my test typing somewhat :).

      Thanks again for your time!

[reply]
[d/l]
[select]

        Thank you everyone for your time!

        I have solved it. It turns out that a combination of my dyslexia and me being a Muppet meant that I had two identically named Bar packages, with substantially different functionality: perl (understandably) was confused as to which one I meant.

        Sometimes I feel that I am an idiot.

        Thanks again for your time! Have a great week!

[reply]
[d/l]

In Section Seekers of Perl Wisdom