Crash with barcode class when building with Xojo2024R2 and using macOS 10.14

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 can’t confirm, but you should definitely report this as an issue…

To me it looks like the Barcode.dylib in Xojo 2024r2 is built to be available/running only with macOS 12.3 (and newer):

otool -l "./Xojo 2024r2.app/Contents/Resources/Internal Plugins/RBBarcode.xojo_plugin/RBBarcode/Build Resources/Mac Universal/Barcode.dylib" | grep minos
    minos 12.3

@Javier_Menendez might know more about that…?


Compared to Xojo 2024r1.1 - where I’d assume the Barcode.dylib is built for macOS 10.9 (and newer):

otool -l ./Xojo\ 2024r1.1.app/Contents/Resources/Internal\ Plugins/RBBarcode.xojo_plugin/RBBarcode/Build\ Resources/Mac\ Universal/Barcode.dylib | grep -A 3 MIN
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.9
      sdk 12.3

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.

From Xcode 14.1+, the minimum supported should be 10.13

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…


vtool -show ./Xojo\ 2024\ Release\ 2/Xojo\ 2024r2.app/Contents/Resources/Internal\ Plugins/RBBarcode.xojo_plugin/RBBarcode/Build\ Resources/Mac\ Universal/Barcode.dylib 

./Xojo 2024 Release 2/Xojo 2024r2.app/Contents/Resources/Internal Plugins/RBBarcode.xojo_plugin/RBBarcode/Build Resources/Mac Universal/Barcode.dylib (architecture x86_64):
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 12.3
      sdk 12.3
   ntools 1
     tool LD
  version 764.0
Load command 11
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0
./Xojo 2024 Release 2/Xojo 2024r2.app/Contents/Resources/Internal Plugins/RBBarcode.xojo_plugin/RBBarcode/Build Resources/Mac Universal/Barcode.dylib (architecture arm64):
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 12.3
      sdk 12.3
   ntools 1
     tool LD
  version 764.0
Load command 11
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

again compared to Xojo 204r1.1:

vtool -show ./Xojo\ 2024\ Release\ 1.1/Xojo\ 2024r1.1.app/Contents/Resources/Internal\ Plugins/RBBarcode.xojo_plugin/RBBarcode/Build\ Resources/Mac\ Universal/Barcode.dylib 
./Xojo 2024 Release 1.1/Xojo 2024r1.1.app/Contents/Resources/Internal Plugins/RBBarcode.xojo_plugin/RBBarcode/Build Resources/Mac Universal/Barcode.dylib (architecture x86_64):
Load command 7
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.9
      sdk 12.3
Load command 8
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0
./Xojo 2024 Release 1.1/Xojo 2024r1.1.app/Contents/Resources/Internal Plugins/RBBarcode.xojo_plugin/RBBarcode/Build Resources/Mac Universal/Barcode.dylib (architecture arm64):
Load command 8
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 12.3
   ntools 1
     tool LD
  version 764.0
Load command 9
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0

Other Xojo Internal Plugins seem to be built ok in Xojo 2024r2, e.g. the SearchControl:

vtool -show ./Xojo\ 2024\ Release\ 2/Xojo\ 2024r2.app/Contents/Resources/Internal\ Plugins/RBSearchField.xojo_plugin/RBSearchField/Build\ Resources/Mac\ Universal/libSearchControl.dylib 
./Xojo 2024 Release 2/Xojo 2024r2.app/Contents/Resources/Internal Plugins/RBSearchField.xojo_plugin/RBSearchField/Build Resources/Mac Universal/libSearchControl.dylib (architecture x86_64):
Load command 7
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.9
      sdk 12.3
Load command 8
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0
./Xojo 2024 Release 2/Xojo 2024r2.app/Contents/Resources/Internal Plugins/RBSearchField.xojo_plugin/RBSearchField/Build Resources/Mac Universal/libSearchControl.dylib (architecture arm64):
Load command 8
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 12.3
   ntools 1
     tool LD
  version 764.0
Load command 9
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0
1 Like

I have created an issue for you:
Issue 76871 | Xojo 2024r2: Barcode.dylib is incorrectly built with minimum OS 12.3

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.

Better sooner than later… it seems a Bugfix Release 2024r2.1 is on the way:
Xojo Issues: Search for Milestone ‘Xojo 202024r2.1’

…and this definitely qualifies for that Milestone :wink:

1 Like

Good pickup. FWIW, the user has confirmed that the same project compiled with Xojo 2024R1.1 runs in 10.14.6,

Looking into it. Thank you for pointing this out! :+1:

2 Likes

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! :+1:

2 Likes

look at my recent report concerning barcode, I suspect it’s the same thing

@Peter_Stys which one? Do you have the issue # around?

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.

There’s something else on the topic too:

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).

i did not formally report it, but it’s a heck of a coincidence that of the 1000s of classes, both involved barcode.

1 Like

@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:

1 Like

Hi @Tim_Parnell,

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.