So I’ve managed to crash calls to my external library a few times and have read conversations about similar issues with declare but can’t make this work. I have created a very simple C library on MacOS, the library call is:
The Xojo side is reading a file into a MemoryBlock and then calling the library and passing the MemoryBlock as a Ptr, unfortunately the library call crashes. The library is only a test lib so it’s not actually doing anything just returning an int of 0.
The Xojo call I’m making is:
declare Function testMethod lib ( ByRef file as Ptr ) as Integer
How does one declare and pass a pointer to a file/memory blob to an external library from Xojo?
There is always the possibility that the test library I created is wonky, I did create a 2nd test library, one that has Double as both arg and return which takes the square root of the number passed and that works from Xojo w/o issue.
should be declared in Xojo as:
declare Function testMethod lib <libName> ( file as Ptr ) as Integer
declaring it as byref Ptr would pass the library call a void ** and that might lead to a crash.
Hey Jason, thanks I tried that already and got the same result, the ByRef was a shot in the dark. Some more info about what the Xojo side is attempting:
The plan is to read in an image file (JPG or PNG) using a BinaryStream and writing that to the MemoryBlock. It’s the pointer to the MemoryBlock that I’m attempting to pass to the test library. Ultimately the library will make it’s own copy, via the passed pointer, and do some work on it returning the Integer as status.
I initially started with the test library taking a char* instead of void* and read a few posts about passing CString vs Ptr etc…but nothing I’ve tried so far has worked. Again the current test library is just a stub so there is nothing being done within that would be causing the crash which is why I think it’s how I’m declaring it on the Xojo side.
Will keep poking around and also check how I’m building the library just in case I’ve missed something there.
I’d double check the size of the int, pointer and integer variables.
maybe your function is working on the basis of 32bit integers, and Xojo is shoving 64bits in that direction.
‘integer’ doesn’t always mean the same thing , depending for example on whether you are building 32 or 64bit
IMO it never hurts to be explicit.
UINT64 or UINT32 instead of integer, for example
Jeff, good point will check it out.
Ok, I believe I’ve got this sorted out, on Jeff’s suggestion I started playing around with 32 vs 64 bit builds, when I tested w/32 bit I got a symbol mangled error instead of the previous (not very helpful) nil exception.
Looking back at my sample library I was building w/the g++ compiler, changing over to rebuild library w/gcc compiler seemed to resolve the issue. I’m assuming that the g++ mangled symbols were causing me grief but nil exception wasn’t pointing me in any particular direction.
Thanks to Jeff and Jason for your suggestions.