Hi,
I'm working with Greg on this project, and have a quick question (as I see Brian's got a backlog of posts to go through) -- off the top of anyone's head, does this look like a fairly simple issue, or is figuring out what's going on with import WRT Inline and source filters likely to take a bit? We're doing a presentation on perl source filters for this weekend's LA.pm gathering (http://la.pm.org), and would like to have working sample code for the talk. Our alternative to getting the Inline version going is to just work off of an existing XS-based stub (Filter::decrypt), but we need to get started on that ASAP if we can't work out this issue rather quickly. Thanks! Abe On 6 Nov 2001, Greg Schueler wrote: > Hi, I'm a fairly new user of Inline. What I've done is written a module > (Test::A) using Inline to access some functions of a shared object > written in C. The shared object is installed in /usr/lib, and it's > header file in /usr/include. I used h2xs to set up the module > directory, and modified Makefile.PL so Inline::MakeMaker is used. I can > build and install this module and it works fine when included and used > in a perl script, and I can test it correctly. > > However, when I try to call a function (func) from within another perl > module's "import" subroutine I get the following error during the > compilation phase of the module: > > Undefined subroutine &A::func called at > /usr/local/lib/perl5/site_perl/5.6.1/Test/B.pm line 22. > BEGIN failed--compilation aborted at test.pl line 10. > > The same error occurs if I call the function with the explicit > namespace: > Test::A::func > > yet > > print join("\n",keys %Test::A::); > > will show "func" in the namespace at that point. > > Is the "import" subroutine called before the actual code for any inline > module is loaded? Is there a way to defer the loading of one module > until another is loaded? I've tried "use Test::A" inside the import > sub, and in a BEGIN block, but although use seems to succeed, the > subroutine remains undefined. > > My real purpose of this was to write a source filter that called > functions defined in a shared library. (yes, a decryption filter. yes, I > know there's no security in it. we just want a little obscurity). > > Anyway, thanks for your time, > Greg Schueler > > >
