System.IsFunctionAvailable

General
1 
If not System.IsFunctionAvailable( "function_name", lib_path_constant ) then
  // FAIL
  MsgBox "[function_name] could not be found at [lib_path_constant]"
  quit
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.

2

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.

3

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

4

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

5

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:

6

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.