On Thu, Jul 12, 2012 at 11:03 AM, McIntyre, Shane K.
<smcint...@mitre.org> wrote:
> I am writing a Perl module (.pm file) that has C++ code in it. When I
> attempt to start up apache and the Perl modules get compiled the C++ method
> in the file does not get bound to Perl. I am not having the same issue with
> other Perl Modules where I use Inline C only ones where I have Inline CPP.
> I am using Perl version 5.8.8. Is there something different that needs to
> be done for C++ vs. C? Right now I have a very basic Perl Module that I’m
> just trying to get to work. The code is below. Any help/guidance you could
> give me would be appreciated.
>
>
>
> use strict;
>
>
>
> use Inline CPP => (‘Config’ =>
>
> DIRECTORY =>
> ‘/projects/langid/apache/_Inline’,
>
> );
>
>
>
> use Inline CPP => <<’END_CPP’;
>
>
>
> double factorial (int x) {
>
> int i;
>
> double result = 1;
>
> for (i=2; i<=x; i++) result *=I;
>
> return result;
>
> }
>
> END_CPP
>
> 1;
>
>
Your code looks reasonable enough. If you turn off AUTOCLEAN (I think
that's the correct name, but check the Inline POD, as I'm going from
memory), you should be able to review a dump of everything that went
on when the code compiled.
I've found that most likely culprits are either Inline::CPP not
guessing the correct C++ compiler on your system, or not guessing the
correct C++ libraries to be linked in. There is also a new kind of
error I'm seeing occasionally where an individual's libraries are not
binary compatible with the version of C++ compiler they're using.
Example: Using libcpp designed for g++ version 4.1, but using g++
compiler version 4.5.
I've done a lot of work on enhancing the portability of Inline::CPP
across as many platforms as I can, but I didn't do it alone; the input
from the inline@perl.org mailing list was crucial in getting the
module to where it is now. If the AUTOCLEAN=>0 dump of how the
compilation phase ran doesn't provide you with any clues, you might
consider posting to the inline mailing list. (I participate there as
well). Putting all of our heads together we might be able to figure
it out. It would probably be helpful if you provided more information
on the failure you're seeing.
One other resource: Look at the cpan testers for Inline::CPP. Find a
"FAIL" in the current version of Inline::CPP that most closely
represents your system's configuration, and failure point. Find a
PASS that also closely represents your system configuration. Look at
the two reports and see if there's anything to be learned by examining
the testers' tool chains.
In the worst case, you might have to compile your code with
Inline::CPP, and then use the XS code it generates directly in your
module, removing the Inline::CPP dependency. In other words, use
Inline::CPP to do the dirty work of creating the XS, but then turn
your module into an XS module rather than an Inline::CPP-based module.
There's a module called InlineX::CPP2XS that can do the conversion
for you.
Sorry to say that as much work as has gone into it, there's still a
small "cross your fingers and hope" factor involved.
Dave
--
David Oswald
daosw...@gmail.com
