I have had problems like this on the Alphas when the perl and the shared libraries
were compiled on machines with different OS revs (we have a heterogeneous cluster
here, with some older machines still running OSF4, and some running TruUNIX 5.1).
Also, the revisions tend to be quite backward compatible, but not forward compatible
-- i.e. things compiled on a 4.0 system tend to run fine on a 5.1 system, but not the
other way around. I've worked around it by building perl (and all XS or Inline C
modules) on one of the 4.0 boxes (which I will need to do until we can finally retire
them...). When I've forgotten to do this, weird things can happen -- e.g. when I
built an Inline::C module on a 5.1 machine (when the perl had been built on a 4.0
machine), some of the function calls worked once, but not the second time, values
weren't always returned, etc. I am sure the compilation can be configured to tell the
5.1 code to link properly with the 4.0, but it is easier just to build on the 4.0
machine.
I've also had problems linking modules compiled with the DEC cc and with those built
by gcc -- I usually just do everything with DEC cc, since that is what I built perl
with. You may want to compare the compilation environments of your perl and the
shared library and ensure they are the same.
Given those caveats, though, I have had no problem with Inline::C on our Alpha UNIX
cluster... Also, Inline::C really just does the yucky XS stuff behind the scenes for
you, so if you can get something to work with XS but not with Inline C I would be
suspicious of your Inline::C configuration.
This may not be your problem, but I hope it helps...
Best of luck,
-Jonathan
--- Begin Message ---
Dear all,
I have been trying to use Inline 0.43 on Alpha Tru64 OSF1 to combine perl
code with the C code that I recently developed. Unfortunately my efforts
have not been successful...
I have this shared library from which I want to access several functions.
The problem is that the shared library crashes when I do a function call
from my Perl Inline script. This problem does not occur when I access the
shared library function from another C-program... The shared library crashes
on normal system calls like malloc, sockets. threads... Now I was wondering?
Are there any restrictions on the type of systemcalls that may be used by
the shared library? Is this maybe a known bug?
I hope that somebody has a clue what is going on here! If not... I probably
have to switch to the use of SWIG or XS... :( which is something I really
don't want!
Best regards,
Marco Kleefman
The Netherlands
--- End Message ---
