Prerequisite Checklist
Describe your issue here
Objective-C has a flat namespace and runtime symbols for class names. This means that within a process, no two Objective-C classes can share a name (see official Apple guidance on this).
In the context of a process which might be using several libraries, which might separately use SFML, we end up with a conflict between e.g. two versions of SFWindow. The Objective-C runtime will use the first one that loads.
This isn’t just a theoretical issue. I am developing a new AU/VST3 plugin for my company. Our previous plugin uses SFML, and the one I am working on now also uses SFML. It is possible for the versions of SFML to diverge between the two plugins — and this is not to mention the possibility that any of the thousands of other plugins available might also be using SFML. If SFML is compiled with all the Objective-C classes named as they currently are, then the first plugin loaded will control which SFWindow is used by all other plugins. One plugin could end up interfacing with a version of SFWindow that it wasn’t built with — which could easily break it.
I have prepared a PR (#3719) with my idea of a solution to this problem, but open to thoughts.
Your Environment
- MacOS 26.2
- SFML version: 3.2.0 dev
- Apple Clang (Xcode)
Steps to reproduce
It's beyond the scope of this issue to describe how to build an AU or VST3 plugin. But in general, if you build 2 dynamic libraries that are both compiled with SFML, and load both libraries in a process, you will get error messages at best, undefined behavior or crashes at worst.
Expected behavior
There should be a way to rename SFML Obj-C classes to prevent name conflicts.
Actual behavior
Hardcoded Obj-C class names cause warnings like this to appear when loading frameworks/dynamic libs:
objc[19016]: Class SFApplication is implemented in both /Applications/App1.app/Contents/Frameworks/App1_AUv3_Framework.framework/Versions/A/App1_AUv3_Framework (0x117cf8be0) and /Applications/App2.app/Contents/Frameworks/App2_AUv3_Framework.framework/Versions/A/App2_AUv3_Framework (0x119720eb8). This may cause spurious casting failures and mysterious crashes. One of the duplicates must be removed or renamed.
objc[19016]: Class SFApplicationDelegate is implemented in both /Applications/App1.app/Contents/Frameworks/App1_AUv3_Framework.framework/Versions/A/App1_AUv3_Framework (0x117cf8c58) and /Applications/App2.app/Contents/Frameworks/App2_AUv3_Framework.framework/Versions/A/App2_AUv3_Framework (0x119720f30). This may cause spurious casting failures and mysterious crashes. One of the duplicates must be removed or renamed.
...
Prerequisite Checklist
Describe your issue here
Objective-C has a flat namespace and runtime symbols for class names. This means that within a process, no two Objective-C classes can share a name (see official Apple guidance on this).
In the context of a process which might be using several libraries, which might separately use SFML, we end up with a conflict between e.g. two versions of SFWindow. The Objective-C runtime will use the first one that loads.
This isn’t just a theoretical issue. I am developing a new AU/VST3 plugin for my company. Our previous plugin uses SFML, and the one I am working on now also uses SFML. It is possible for the versions of SFML to diverge between the two plugins — and this is not to mention the possibility that any of the thousands of other plugins available might also be using SFML. If SFML is compiled with all the Objective-C classes named as they currently are, then the first plugin loaded will control which SFWindow is used by all other plugins. One plugin could end up interfacing with a version of SFWindow that it wasn’t built with — which could easily break it.
I have prepared a PR (#3719) with my idea of a solution to this problem, but open to thoughts.
Your Environment
Steps to reproduce
It's beyond the scope of this issue to describe how to build an AU or VST3 plugin. But in general, if you build 2 dynamic libraries that are both compiled with SFML, and load both libraries in a process, you will get error messages at best, undefined behavior or crashes at worst.
Expected behavior
There should be a way to rename SFML Obj-C classes to prevent name conflicts.
Actual behavior
Hardcoded Obj-C class names cause warnings like this to appear when loading frameworks/dynamic libs: