I have an app that includes barcode scanning. I know you need macOS 15 to use the barcode scan class, but the function is only exposed if the user is running macOS 15 (Catalina) or later, so that is not an issue. A build made with Xojo2024R1.1 was widely distributed and there were no reports of problems.
I recently released an app update, built with Xojo2024R2, in which the barcode scanning code wasn’t touched. Today I was contacted by a user who says he can’t launch it on a Mac running 10.14.6. He gets this error:
Runtime Error: Location: Common/plugin.cpp:1048 Condition: false Message: Could not open plugin Barcode.dylib (dlopen(/Applications/MyApp_1504.app/Contents/Frameworks/Barcode.dylib, 5): no suitable image found. Did find: /Applications/MyApp_1504.app/Contents/Frameworks/Barcode.dylib: cannot load 'Barcode.dylib' (load command 0x80000034 is unknown) /Applications/MyApp_1504.app/Contents/Frameworks/Barcode.dylib: cannot load 'Barcode.dylib' (load command 0x80000034 is unknown))
He confirmed that the previous version launches normally on that machine. And that the current version works fine on another Mac running macOS 14.5.
I’m wondering if there was a regression in Xojo2024R2. Can anyone confirm that apps that include the barcode scan class run in versions of macOS prior to Catalina?
I guess that that dylib was built using different SDK targets and things got messed. I’ve heard something like that in another environment, introduced by XCode 14+ that forced some upgrades and needed compatibility declarations set to a lower compatibility compilation using newer SDKs or the new dylibs would just crash like that “command unknown”.
@William_Yu would know better, and he can check if that dylib was build using a different target environment/sdk than the rest. I guess that something may be out of sync.
vtool shows this better (you see the min os versions for both architectures: x86_64, arm64…
…and as far as I remember arm64 is only available with macOS 11 (and newer), so the way Xojo 2024r1.1 has this internal Plugin seems correct to me.
Definitely a build issue of Xojo 2024r2 that needs to be looked at by Xojo, as this does not fit with their minimum requirements for built applications…
Thanks. I made a new build with Xojo2024R1.1 and sent it to the user. I was going to create the issue as soon as he confirmed that it ran on his Mac running 10.14.6.
Ok, so the minos for the Barcode plugin on macOS is set now to 10.14 (somehow it was set to 12.3 in the project)… and it should work properly, Please don’t forget to check & report if it is not the case!
He maybe never reported it into the issues tracker. He had a weird issue reported in the forum as a cache related issue, sometimes working, sometimes not, at the development level, about the symbol _barcode no being found.
Nope, these are not related. The first one has to do with the cache, while the second one is just because the Scan feature is only available on macOS 10.15+ (it raises an Unsupported Operation that can be catch in Xojo code).
@Javier_Menendez I received a report from a Web user that an issue just like this is occurring with Web because headless Linux doesn’t have GTK. Please set the platform support flags in the Barcode plugin appropriately so that using Barcode in Console or Web causes a compiler error. This will help people find issues before they even reach runtime.
Thankfully the documentation is correct and we were able to track down the issue quickly.
To illustrate how useful this can be, here’s what happens when you attempt to use Keychain in a Console app:
A headless Linux server should still be able to create codes and even read them from received pictures. Only when trying to “Scan” codes (operation that requires UI) the UnsupportedOperation exception should be raised… and handled in code to avoid this kind of crashes (in case such code is shared among Desktop / Web / Console / iOS projects, for example). This also applies to any Console app on any of the supported OSs.