Need help with porting to MacOS

[bobby100]

It is about this project here:
https://github.com/BobanSpasic/MiniDexedLibrarian

I don't have a Mac, but I did try to compile in a VM. My experience with MacOS in general is zero.
I've installed Lazarus and the needed components. There was a catch to install Eye Candy components, but I found the answer here in the forum.
The app on the link above should theoretically work on MacOS because I use portmidi (it "should be" cross-platform) for MidiOut.

So, I've installed the portmidi by using MacPorts.
When I try to compile the app, the linker can't find the symbol Pm_Terminate.
If I comment out Pm_Terminate allover the place, the linker stops at not finding Pm_WriteSysEx. I didn't try further.

So, I do believe that the linker found at least something from portmidi library, because there are other imports before Pm_Terminate and I guess that these symbols were found. I have no clue how can I check anything here as I have zero experience with MacOS.

Could someone give me a hand here?

[Jonas Maebe]

The problem is that the your portmidi unit tells the compiler which symbol names to use for the external symbols, and those names are wrong for macOS. You can fix it by removing all of the "name 'xxx'" modifiers from that unit, so that the compiler can perform the correct name mangling depending on the target platform.

[bobby100]

Hi Jonas, thank you for helping.
I did as you say, but it didn't help.
Compiling in Debug mode throws an error at symbol Pm_Close, and compiling Release mode stops at Pm_WriteSysEx.
I checked the library with nm command and I can see the functions present. These are also in header file.
I even tried to start Lazarus with sudo (perhaps a problem with permissions), but nothing changed.

Any other ideas?

[Jonas Maebe]

The symbols will be present with an extra underscore at the start (if they're not, then the library itself would be compiled wrongly; macOS reserves symbol names that don't start with an underscore for OS internal usage). You can try adding "cdecl;" to the declarations, although I would expect the {$calling cdecl} at the top of the unit already taking care of that.

It's how the RTL also links against libc, so it definitely works. If it still doesn't work with your unit, I don't know what the problem is.

[bobby100]

Solved. Thank you for helping.

First, I got the modified portmidi.pp from USDX sources: https://github.com/UltraStar-Deluxe/USDX/tree/master/src/lib/portmidi as I saw that they have some Darwin-related changes/IFDEFs.
It didn't help right away, but it was my fault. I needed to set the Library path in Project Options to point to /usr/local/lib. Dunno if it would now also work with the old portmidi.pp, I didn't test that.
It is something that I didn't need on Linux or FreeBSD, so I didn't expect it to be needed here either.
Now, it compiles, it gets linked, but with a warning that the libportmidi is compiled for MacOS 12 (I am using Catalina). Starting the app works anyway. I could not test the MIDI functions as I have no MIDI devices in the VM, so the listboxes on the Settings tab are empty.

Interesting fact - Eye Candy controls are painted faster on Qt5 Linux and FreeBSD in VM as on Windows on the real hardware. Also fast on MacOS VM, much faster than on Windows running on real hardware. On Win, you can see the repainting of the components at changing tabs.