TDR has asked for the wisdom of the Perl Monks concerning the following question:

Well my problem is kind of compilcated. I have a c program
that calls some perl function to allow my c program to access perl scripts. The c program was compiled with g++ 2.95.3 and it worked with 97r1.3 version of perl just fine but recently my department upgraded to perl 5.8.5. But the problem is the libperl.so (for 97r1.3)which is used by the c program originally was compiled using g++ 2.8.1 but this new one's (5.8.5 perl) libperl.so was compiled with g++ 3.3.3 so I'm getting sigmentation bus error or something like that which doesn't create a core file. At least I think this is the problem.

So I was wondering how can I solve this problem? I was thinking of migrating my c program to g++ 3.3.3 but it would take an immense amount of effort (it's very big). I thought of trying to compile my own 5.8.5 perl libperl.so using g++ 2.95.3 but I had a very big wall on that solution.

I'm not sure if this is the right forum to post, if it's not please direct me to the correct one.

Thanks for the help in advance.

TDR

Replies are listed 'Best First'.
Re: problem with libperl.so
by Corion (Patriarch) on Sep 30, 2005 at 07:13 UTC

    There is no Perl with version 97r1.3.

    The general rule for binary compatibility between Perl versions is, that binary compatibility is supposed to be maintained between the Perl5 minor releases. So in theory, all versions of Perl 5.8.x are binary compatible among each other, as are all versions of Perl 5.6.x. In practice, this also depends on whether your Perl is built with threading enabled and if it's built with 64-bit support enabled, and some other compile-time options.

    My rule of thumb is to use one C compiler for both, Perl and its extensions, and that would extend in your case to using one C compiler for all, Perl, your C program, and all Perl extensions. This means that you will have to either recompile Perl with gcc 2.81 (I don't know if that ancient gcc works well, as the only "old" gcc I know/use is 2.95), or have to recompile your C program with gcc 3.3.3.

    If you go the easier route of compiling your own private Perl with gcc 2.8.1, you should find ample debugging output when you run ./Configure to configure the version of Perl. Having "a big wall" is not an error message I recognize, so maybe you could post the (full) output of the Configure run instead.

[reply]
[d/l]
Re: problem with libperl.so
by Zaxo (Archbishop) on Sep 30, 2005 at 07:17 UTC

    Find out what compiler/version was used to build the current perl, and recompile your app with it. g++ 3 is considerably fussier than v2 was about correct C++, particularly wrt namespaces. Most of the needed corrections are not too complicated; you may be able to get perl to do some of the editing for you!

    It might be worthwhile to split the perl-calling functions off into a dll of their own. That would likely be the only thing needing recompilation with a change of perl.

    After Compline,
    Zaxo

[reply]
Re: problem with libperl.so
by TDR (Initiate) on Oct 11, 2005 at 07:53 UTC
    Actually 97r1.3 is 5.00404
[reply]

Back to Seekers of Perl Wisdom