Dylib Declare Function Not Found

Targets macOS
1

I’m trying to access one function in a small third party C dylib. I can successfully use dlopen to open the dylib. I can even use dlsym to get a handle to the function I want to call. System.IsFunctionAvailable returns true for the function I want.

But whenever I try to actually call the function I get a Function Not Found exception.

dylib function is:

int encode_file(char const * in, char const * out)

Declare Function encode_file Lib "@ExecutablePath/../Frameworks/lzss.dylib" (Ifile as CString, Ofile as CString  ) As Integer
var Infile as CString = fin.NativePath
var OutFile as CString = fTemp.NativePath
var result as integer = encode_file(Infile, Outfile)

What else can cause the function to not load or be callable? Are certain access rights needed on the dylib to make it executable? (It’s in my app’s Frameworks folder) If I had the parameter types wrong would that give a Function Not Found exception? Is code signing now required to use a third party dylib? I’m on OSX 15.1.1

2

Are you actually using dlopen to load that dylib before using it? You might need to.

Also, make sure the dylib is getting signed with your cert. It probably can’t be loaded if it’s not.

3

Hi Greg Thanks for the suggestions. Yes I use dlopen to load and link the dylib before the declare and attempt to call the function in the dylib. The dlopen call returns success.

I have not yet learned how to sign the dylib, it came precompiled but I do have the C source code. I just signed up for an Apple Developer ID.

I was hoping to use the Xojo hardened runtime options to allow loading the existing dylib. But I suppose I can also try to figure out how to sign the dylib with my new Apple Dev ID. Would I need to recompile it?

4

You don’t need to recompile. I would expect the IDE to be able to do this for you, but it’s possible that there’s still an issue.

I use this tool to check signatures

5

Hi Greg Great tips! I think I’ve (finally) gotten everything signed.

I also had some path issues in the Declare but I think I have those straightened out. The call to the function in the dylib finally doesn’t cause an exception and seems to perform properly, I’ll have to test some more to be sure.

Thanks for all of your great help!

Cheers,
Joe

1 Like
6

For others with a similar problem I should mention that the final issue was specifying the right path to the dylib in the Declare statement.

dlopen needed to be called like this, including @executable_path

dlopen("@executable_path/../Frameworks/" + "LZSS.dylib" + "", 13)

However Xojo apparently prepends its own @executable_path to the Declare path given so the Declare needs to look like this

Declare Function encode_file Lib "../Frameworks/lzss.dylib" ( Ifile as CString,  Ofile as CString  ) As Integer

The way I figured this out was to call the problematic dylib function in a Try block and use dlerror in the Catch block to see the returned error before Xojo threw the exception. The dlerror message showed duplicate @executable_path segments in the dylib path. So I deleted the one in my Declare and finally things started working.

2 Likes
8

It shouldn’t be doing that. There are other things you might want to put instead of @executable_path.

That would also be a serious behavior change that would affect most advanced Xojo projects.

9

I wonder if it has to do with my CopyFiles Build step???

An additional problem is that the function in this dylib works fine the first time it’s called but seems to retain some kind of state because it gives different results on each subsequent call to the same function. So to get the proper behavior I have to close and reopen the dylib between each call to that function. I think I’m going to pursue an alternative strategy that doesn’t use this dylib at all.