ki-bo
commented
2 years ago These are different problems.
- The minimum deployment target version may be configurable when doing the xojo build of the m65connect main binary. Something to check whether this is easy to adapt or if we have a real reason for that limitation. It might just be a default setting.
- The underlying command-line tools in the Resources sub-folder of the m65connect app also need to be compiled with deployment target 10.9. This is possible, but first tests indicate that a 10.9 macOS, while still executing, gives an error when setting the baudrate of the uart to 2000000 bps. It is the same code as for the later macOS versions, so maybe the old 10.9 doesn't support this way of baudrate configuration.
- M1 support: The problem is not that M1 support is missing, but rater that it is currently implemented partly. If all parts of m65connect would be Intel (x86_64) only, macOS would automatically chose the Rosetta emulation for it and that would in fact be fine. But at the moment, the main binary m65connect is a universal binary, meaning it is compiled for bot x86_64 and arm64 (=M1 or M2). When starting the main app, macOS running on an M1 processor will see the arm64 part being available and start it up with the arm architecture and without Rosetta. No problem so far, it will run. But at some point it will use the ftdxx dynamic library in the Resources folder which is not a universal binary. Since the main process is already running arm64, this dylib can't be loaded (it is x86_64 only), and this is the reason for the errors provided when run on M1.
- Finally, we have the problem that m65connect currently comes with most of the needed libraries it needs to run (in the Resources folder), but one of the needed ones is missing: libusb-1.0. Therefore, the m65.osx command-line tool that comes with m65connect will not start on systems that don't have libusb for x86_64 installed somewhere. On machines of developers, this is not a problem, the libraries are installed in the expected folder of the OS, but for users just downloading the app from Filehost, this will throw errors complaining about the usb communication not working.
We need to decide how to tackle all of those small issues to get an app bundle with no dependencies and that will run out-of-the-box for users both on x86_64 and arm64 processors.
First questions to start the discussion: do we have an arm64 version of the libftdxx that's shipped in the Resources folder? Where is it from? If we can't get an arm64 build of that library, we should rather stay on x86_64 for the whole app, and try to re-compile the xojo main binary for Intel only.
Taygair
Needs MacOS 10.10 minimum - but why? Can’t update my old iMac, using 10.9.5
USB driver problem on M1