@executable_path no longer works? Xojo team please help

Xojo2022r4.1 Mac Studio M1

I have a question for the Xojo team: in your IDE project, how do you write your paths to the dylibs in the Frameworks folder? Are you writing @executable_path/…/Frameworks/libname.dylib ? Because that is not working for me.

Let me try to explain.

My project using external dylibs has been working for over a decade. The parent dylib (which has a lot of dependency libs also copied into the Frameworks folder) is accessed using constant in the form:


This has stopped working recently. I read that SIP prevents @executable_path from working directly, and Apple now requires using @rpath which then can point to the @executable_path

I know how to set all that up using install_name_tool in the terminal. (install_name_tool -add_rpath, then install_name_tool -change to point to the rpath).

But it still doesn’t work. It seems that Xojo simply can’t find the dylibs, no matter what I do, because this path @executable_path no longer works. When I point to dylibs installed on my machine using an absolute path in the constant, that works, which would suggest that it’s not the dylibs causing the problem, it’s this path constant.

Please tell me how to write the path so that it will work. Thank you.

What is not working for you? I’m still using a super old dylib with the following path:


And it works fine. Xojo 2022r4 on Ventuna 13.1 beta.

Hm, that’s interesting.

I get a “function not available” error, testing System.IsFunctionAvailable This error message tells absolutely nothing about the cause, which could be any of the following:

  1. the library doesn’t contain the function
  2. the library isn’t compiled correctly
  3. the library has a dependency that can’t be found
  4. the library doesn’t exist
  5. the library exists but the path to it is wrong
  • etc.?

So I use these facts to try to figure out which case it is:

  • This is the same library that exists on my system, and it works fine when called from there using an absolute path.
  • I have included all dependencies that aren’t in normal lib directories like usr/lib or System/Library/Frameworks, and I’ve correctly changed all the dependency paths for those libraries

That rules out 1, 2, 3, and 4, and leaves 5, which is why I’ve asked Xojo this question.

It would be better if there were specific tests which would point to a specific problem, but as far as I know, there aren’t? If it’s not the path, then what’s the problem?

Other facts:

  • Changing build from Universal to 64-bit or ARM makes no difference.
  • The compiled app gives the same error.
  • Using Run Paused and codesigning all the dylibs, then launching the build, makes no difference

Are you running an M1 mac or Intel?

Well, I’ve just spotted something … I have to remind myself that the name of the library does not say anything about the compiled version of that library. libwhatever.0.1.5.dylib doesn’t tell you its version. I just noticed that some of these have the right names, but the wrong version compatibility numbers when getting info with otool. This has to be the cause. The mistake must have been made when copying over the dependencies - some were apparently taken from wrong directories. So I think I know how to fix this. Too bad changing all the path names takes tedious hours entering brainless terminal commands, with no guarantee that anything is going to actually work …

After copying over all dependencies from exactly the locations they should be copied from, and changing all the paths with install_name_tool, the same error is given.

If anyone could provide any help debugging this, I would really appreciate it. For now, I’m giving up.

Happy new year (guten Rutsch)

I lied. I didn’t give up. I scoured the files again and found one library, whose name was an alias in the original directory, which had to be changed to a different name. And …

… now it works!


Sorry Xojo team for trying to bother you on New Year’s Eve.

I love using Xojo and I really appreciate this community. Peace everybody.