Error loading Carbon library in Sonoma

[ccesarcaball]

Im using MacOS Sonoma 14.0, I'm able to build the app, but I can't run it, this is the error:

Traceback (most recent call last):
  File "/Users/cccaballero/Projects/services-manager/dist/services_manager.app/Contents/Resources/__boot__.py", line 321, in <module>
    _argv_emulation()
  File "/Users/cccaballero/Projects/services-manager/dist/services_manager.app/Contents/Resources/__boot__.py", line 318, in _argv_emulation
    _run_argvemulator()
  File "/Users/cccaballero/Projects/services-manager/dist/services_manager.app/Contents/Resources/__boot__.py", line 127, in _run_argvemulator
    carbon = _ctypes_setup()
  File "/Users/cccaballero/Projects/services-manager/dist/services_manager.app/Contents/Resources/__boot__.py", line 51, in _ctypes_setup
    carbon = ctypes.CDLL("/System/Library/Carbon.framework/Carbon")
  File "ctypes/__init__.pyc", line 366, in __init__
OSError: dlopen(/System/Library/Carbon.framework/Carbon, 0x0006): tried: '/System/Library/Carbon.framework/Carbon' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/System/Library/Carbon.framework/Carbon' (no such file), '/System/Library/Carbon.framework/Carbon' (no such file, not in dyld cache)

[culler]

This is an Apple bug. They are shipping their Carbon.framework with a broken symlink:

$ file /System/Library/Frameworks/Carbon.framework/Carbon
/System/Library/Frameworks/Carbon.framework/Carbon: broken symbolic link to Versions/Current/Carbon

However, this is not new with Sonoma. It was also a broken link in Ventura.

[ccesarcaball]

I don't know why it doesn't surprise me... any workaround?

[yesyves]

I have the same problem in Frescobaldi but I'm not sure the problem is an "Apple bug" first because the dlerror comes from looking in the wrong directory : OSError: dlopen(/System/Library/Carbon.framework/Carbon, 0x0006)
While it should be looking in /System/Library/Frameworks/Carbon.framework/Carbon

But also since Carbon framework is deprecated since 10.8 (2012) and has no 64-bits support while macOS supports only 64-bit since 10.15 Catalina.

[yesyves]

any workaround?
You can launch the python application from Terminal directly without using the .app wrapper

[culler]

While it should be looking in /System/Library/Frameworks/Carbon.framework/Carbon

There is no such directory. Instead that is the pathname of a broken symlink, and that broken symlink was put there by Apple. The expectation is that Carbon would be a dynamic library that could be opened by dlopen, not a directory.

I don't know of any workaround other than removing dependence on a library which no longer exists.

[GautamBose]

Is this affecting all builds on Ventura? Or only those with a specific dependency?

[matagus]

Just in case it helps, I run into the same issue in this project using rumps + py2app. This workaround worked for me.

[GautamBose]

@matagus Worked for me thanks!

[ryandesign]

While it should be looking in /System/Library/Frameworks/Carbon.framework/Carbon

There is no such directory. Instead that is the pathname of a broken symlink, and that broken symlink was put there by Apple. The expectation is that Carbon would be a dynamic library that could be opened by dlopen, not a directory.

While you're right about the symlink being broken, I think you may misunderstand how libraries work on macOS these days.

I do see this /System/Library/Frameworks/Carbon.framework/Carbon symlink on my systems running macOS 13.7.1 and 14.7.1 and I agree that what it points to does not exist on disk. On my systems running macOS 11.7.10, 12.7.6, and 15.1.1, the broken symlink is not present. The existence of the broken symlink on macOS 13 and 14 is a bug (I've reported it to Apple as FB15950865) but as far as I know it shouldn't cause any problems because it won't ever be used by anything.

Whenever macOS looks for system libraries dynamically linked to a program it's launching, or when a program uses dlopen to open a system library, it is loaded from the dyld shared cache, not from the file at its path on disk. Because of this, in macOS 11 and later, Apple removed the files from disk to save space, since they weren't used.

If you use file /System/Library/Frameworks/Carbon.framework/Carbon you will either see the broken symlink (if on buggy versions of macOS 13 or 14) or a No such file or directory error. But you can use dyld_info /System/Library/Frameworks/Carbon.framework/Carbon (on macOS 12 or later) to verify that it is indeed in the dyld shared cache as it should be.

The bug is that py2app has the wrong path for the Carbon framework:

py2app/src/py2app/bootstrap/_argv_emulator.py

Line 34 in 487a55e

carbon = ctypes.CDLL("/System/Library/Carbon.framework/Carbon")

It's missing the Frameworks directory component. That path has never existed on disk or in the dyld shared cache in any version of macOS so I'm not sure how that code ever worked. I've submitted #537 to fix the path.

However, since Carbon was a transitional technology to help developers move from Mac OS 9 to Mac OS X, and since it has never had a 64-bit version, I'm not sure why py2app is trying to use it at all. I leave excising the Carbon code from py2app to someone who is more familiar with py2app's code.

[jmroot]

However, since Carbon was a transitional technology to help developers move from Mac OS 9 to Mac OS X, and since it has never had a 64-bit version, I'm not sure why py2app is trying to use it at all.

While it exports far fewer symbols than the 32-bit version, there is a 64-bit Carbon framework that provides a few bits and pieces that have (or at least at one time had) no other 64-bit equivalent.

[culler]

Specifically, Tk loads the Carbon framework, and _tkinter loads Tk.

However, I don't see why that requires py2app to do anything with the Carbon framework. The framework exists on the system and can be used if needed.

[MaddTheSane]

Doing a cursory glance at the file that includes the Carbon framework, it uses functions that are actually in CoreServices (and probably were in CoreServices since CoreServices was a framework). It looks like py2app uses the AppleEvents APIs to better integrate with the system. Correction: There's one Carbon function it actually calls: ReceiveNextEvent. And yes, it's still present on macOS' 64-bit runtime. It looks like py2app uses AppleEvents to emulate argc/argv on app launch. I can't find any other references to Carbon.
Also, it doesn't matter that the functions are in CoreServices. Carbon re-exports the symbols of a lot of frameworks.