If not System.IsFunctionAvailable( "function_name", lib_path_constant ) then
  // FAIL
  MsgBox "[function_name] could not be found at [lib_path_constant]"
end if

The reason for a failure can be a few things:

  1. lib_path_constant is wrong
  2. the library file is in the wrong place
  3. function_name is wrong
  4. ?

I have ruled out 1, 2 and 3. The constant is correct, the file exists, and the function name is correct.

Could it be:
4. another library (dependancy) is missing?

The problem occurs in the built app only. It’s working in DebugBuild, with lib_path_constant pointing directly to the installed library in /usr/ etc. In this case I don’t have to worry about dependancies, everything works…

For the built app, I have used otool -L to find all dependancies and name_change_tool to change paths for dependencies. The dylib and all dependancies are copied to the app bundle inside the MacOS folder and the lib_path_constant is changed to @executable_path/libname.dylib

This basic approach has worked fine for about a decade, in 32-bits. I’m now updating to the 64-bit library. The code handling the library has been updated for 64-bits, and it all works fine in DebugBuild. Embedding the dylibs in the app is failing and I’m trying to figure out why.

IsFunctionAvailable reports the same error whether the dylib exists or not. Is there a way to determine if the dylib is actually being loaded?

I thought maybe the permissions of the dylib files were wrong, so the dylib couldn’t be read at all, but the permissions weren’t wrong. They were read/write. I tried defining them as read-only. No change.

… I think I’ve found a missing dependency, will report back.

dont know if this would affect it but shouldnt your dylib be in @executable_path/…/Frameworks ?

It would normally get put there, but it shouldn’t make a difference. There are 12 other dylibs required as dependencies, and I just wanted to keep the default paths simpler.

The library’s original default path points to an alias, which then points back to the library. That confused me for a moment and I thought I had forgotten to include a dependency because the alias has a different name. A red herring …

But, following a tip from your 2011 blog post, I tried copying the original library and putting it beside the DebugBuild bundle using a constant “@executable_path/…/…/…/mylib.dylib”, did a Run/Paused and put the libs in the bundle, manually launched the debug app, and to my amazement, it worked.

So I dragged everything one last time and put it in the built app in the same place I’ve been putting it all along… and now it works.

I have absolutely no idea why it hasn’t been working for the last 5 hours, and now all of a sudden it works.

In any case, thank you Norman, for your advice and for the blog post which seems to mysteriously have saved the day :slight_smile:

What must have happened is that some invisible character somehow got copied into the constant definition for the library path. It’s not inconceivable, since I’ve been working on 2 machines which are set to different languages (one is English and the other German) and have been copying things back and forth, and there is a bug in Xojo which prohibits pasting a value directly into the constant in the list (instead the little (…) icon at the right has to be clicked and the test can be pasted into the drop-down window) so I had been using BBEdit on one system and TextEdit on the other for text clippings of different paths (I guess TextEdit was probably the culprit). I wanted to build the libraries on a clean system and then transfer the libraries to my old workhorse, so I would be sure to have the right files and no conflicts, this is why I was using 2 systems all day today. Unless anyone has a better idea, I am guessing this is what it was. In the course of the day I also ran into one bad character in a Terminal command which stumped me for about 15 minutes. The German system had interpolated a slanted double quote on one of the entries.