Application doesn't start: Namespace DYLD, Code 1 Library missing

I have a multi-platform application made with Delphi which uses FTDI D2XX drivers. All is well in other platforms but i have this issue in MacOS when i try to start the application:

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: libftd2xx.dylib
Referenced from: <CD2148C0-F76F-35D5-8E65-2BE51F201302> /Users/USER/*/USB_Editor.app/Contents/MacOS/USB_Editor
Reason: tried: 'libftd2xx.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibftd2xx.dylib' (no such file), 'libftd2xx.dylib' (no such file), '//libftd2xx.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS//libftd2xx.dylib' (no such file), '//libftd2xx.dylib' (no such file)
(terminated at launch; ignore backtrace)

If i try to run the executable i get a similar error which includes the users/user folder in the paths specified above. So if i copy libftd2xx.dylib to users/user the app can start from the executable and the USB library works well.

The library is bundled in Contents/Framework as this seems to be the best (or only) accepted practice. Btw the app only starts during deployment if the library is found in Contents/MacOS.

Library version is the most recent from FTDI site for the ARM architecture and followed their instructions to install.

If i try the otool command on the library i get this:

otool -L libftd2xx.dylib

libftd2xx.dylib:
	libftd2xx.dylib (compatibility version 1.1.0, current version 1.4.30)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2202.0.0)

I'm a Mac user since last week so my knowledge of the system is not so good yet (:

Answered by DTS Engineer in 807914022

This is one of those “what’s possible” versus “what’s a good idea” moments. It may be possible to make this work as things are currently set up, but it’s probably not a good idea (-:

The specific issue here is the install name of your library. There are two standard ways of setting that up, a topic I discuss in detail in Dynamic Library Identification. IMO you should follow the standard approach here, that is, change your library’s install name to rpath-relative. Once you do that, things will go more smoothly.

Library version is the most recent from FTDI site for the ARM architecture and followed their instructions to install.

Given that you don’t create the library, you’ll have to change the install name yourself. Embedding nonstandard code structures in a bundle explains how to do that.

I also recommend that you discuss this with the library’s vendor. If they built the library with an rpath-relative install name, everyone’s life would be much easier.

Oh, other comment about the quote above: When working on Apple platforms, it’s important to note that architecture and platform are different things, and you need to get both right. I discuss that in more detail in An Apple Library Primer.

I'm a Mac user since last week so my knowledge of the system is not so good yet (:

Hey hey! The fact that you actually made it to this roadblock indicates that you’re making good progress (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer

This is one of those “what’s possible” versus “what’s a good idea” moments. It may be possible to make this work as things are currently set up, but it’s probably not a good idea (-:

The specific issue here is the install name of your library. There are two standard ways of setting that up, a topic I discuss in detail in Dynamic Library Identification. IMO you should follow the standard approach here, that is, change your library’s install name to rpath-relative. Once you do that, things will go more smoothly.

Library version is the most recent from FTDI site for the ARM architecture and followed their instructions to install.

Given that you don’t create the library, you’ll have to change the install name yourself. Embedding nonstandard code structures in a bundle explains how to do that.

I also recommend that you discuss this with the library’s vendor. If they built the library with an rpath-relative install name, everyone’s life would be much easier.

Oh, other comment about the quote above: When working on Apple platforms, it’s important to note that architecture and platform are different things, and you need to get both right. I discuss that in more detail in An Apple Library Primer.

I'm a Mac user since last week so my knowledge of the system is not so good yet (:

Hey hey! The fact that you actually made it to this roadblock indicates that you’re making good progress (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hey!

i just shared this thread with FTDI and hope they will take the request in consideration.

Meantime i will try to change the install name to relative path as from documentation. So i have a plan B at least (:

Thank you for supporting!

Application doesn't start: Namespace DYLD, Code 1 Library missing
 
 
Q