News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

New Macintosh release

Started by prissi, January 05, 2020, 07:15:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

prissi

I have tried github actions to build an MAC OS release. Lacking MAC OS, I could not test the result. Could someone with a MAC please download and test it, please?

It probably requires SDL2, frettype, and miniunpnpc. Again, no way to test.

DrSuperGood

So what needs testing? Building on MacOS? Or running a pre-built on MacOS?

prissi

It is a nightly build on Mac OS using github actions. I have no idea if it actually runs on a vanilla Mac OS. Maybe it needs more static linking ...

TurfIt

Doesn't work on my ancient Mavericks box - requires QTKit not AVF. i.e. Don't set AV_FOUNDATION=1 in config.default. I have nothing that can run a newer OS to try.

dyld: Symbol not found: _OBJC_CLASS_$_AVMIDIPlayer
  Referenced from: /Users/..././simutrans
  Expected in: /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation
in /Users/..././simutrans
Trace/BPT trap: 5


It looks like you've used 'homebrew' for libraries rather than native mac ones as previous releases have used (I couldn't find native libraries for freetype or miniupnpc which is why the last release for mac had those disabled. [and sidenote - I see release files for a 121.0 version on sourceforge but the forum still shows 120.4 as latest and even has an announce thread for 120.4.1 in the forum too...)

This rather increases Simutrans dependencies from a simple SDL2 framework install to an entire homebrew suite and special brew packages for sdl2, freetype, upnp...  It took >45 minutes to get all that installed - I doubt a typical mac user would bother past the first crash.

Also, the binary should be put in the bundle for friendliness of not having an extra console window open (and then get stuck open until manually closed). I'd provided both the app bundle for normal use (shows only the simutrans window), and the regular executable (also shows the console) in past releases. Actually it's the same executable, just seems macos suppresses the console when run from an app bundle. buildOSXbundle.sh is the script in trunk to do as it says, although outdated so I just did it manually.

prissi

#4
Well, turns out the distribute.sh is not downloading SDL2 and packing for MacOS, since it uses the obsolete darwin os type ... (And the build environment at github only supports AVfoundatiohs anyway). So now I bundle with SDL2. Linking with freetype should create no issue, as freetype is with MacOS. (However, the header I need to download with brew, I hope this creates no further issues.)

The build would be at https://github.com/prissi/simutrans/releases/download/Nightly/simumac-nightly.zip

EDIT: Bundling with DMG seems more complex on macos commandline. So no recent build on the above link!

prissi

Could someone try again this version again https://github.com/prissi/simutrans/releases/download/Nightly/simumac-nightly.zip. It is just assuming one had installed SDL2 via DMG download.

TurfIt

It's still looking for the homebrew freetype:

dyld: Library not loaded: /usr/local/opt/freetype/lib/libfreetype.6.dylib
  Referenced from: /Users/.../simutrans.app/Contents/MacOS/simutrans
  Reason: image not found
Trace/BPT trap: 5

CannonBall7

I've posted some commits to a fork of the simutrans git mirror (https://github.com/EricFromCanada/simutrans) which should help get the Mac nightly build working again by e.g. including a pakset and integrating the shared libraries into the app bundle. With changes applied, rough instructions for building the nightly on macOS are:

- install build dependencies from Homebrew (https://brew.sh):
  brew install autoconf automake freetype libpng pkg-config sdl2
- compile:
  autoreconf -ivf
  ./configure CC=clang
  make BACKEND=sdl2 MULTI_THREAD=1 OPTIMISE=1 OSTYPE=mac USE_FREETYPE=1 USE_UPNP=0 USE_ZSTD=0 AV_FOUNDATION=1
  make OSX/getversion
- build app and compress for distribution:
  ./distribute.sh

prissi

This is very helpful. Just a question: Will this run without brew installed at the end user. Because if brew is required, this would be a no go.

Somehow your workflow does not show action builds. Did you test it with the github actions?

CannonBall7

The install_name_tool lines in distribute.sh modify the simutrans binary to look for shared libraries inside the app's Frameworks folder, so it should run without needing any dependencies installed using Homebrew. I've only tested building in my own Terminal though; I haven't tested anything with GitHub Actions so far.

prissi

I submitted your changes in r9205. Lets see if this generates an universal build

mark1878

I have tried the new nightly download.
The app just exits
If I run the executable in the app from the command line it asks me for a pak
I chose the British pak - it then downloaded and then runs.
A fix to this might be to puit a pak in the bundle and either load from the bundle and a downloading place or copy from the bundle to a downloading place (probably

I also tried a build from source (after passing around the correct flags  - I use Macports so need to add to the include and lib paths) I get error
FATAL ERROR: loadsave_t::rdwr_xml_number() - expected "<i8>", got ""
when trying to read simutrans.xml
Where is this file I can't find it but it is opened somehow

makie

QuoteThe solution: go to %user/documents/simutrans and delete the files default.sve and settings.xml. Deleting both files will make the game generate new default ones and it will work just fine.
the files are where the saves stored
I don't know where in mac maybe in the home directory of the user

prissi

I think for Linux and MAC a call to gat_pak.sh to install some pakset might be the best solution. So Simutrans gets its own update dialog. (May still fail if neither unzip wget or curl is on the machine.)

mark1878

#14
I reran the app from the overnight build. It works if you unzip the whole release but if you move the app somewhere else it then fails.

Looking at bits of code my guess is that it is using the directory the app is in to load data. Unfortunately this is not the Mac way. This might be OK for manual use but not for Steam.

Everything that is needed to start must be inside the bundle.

I also note that osx.mk has a bundle target that is still active, but the code there still refers to PPC builds so is probably 10 years old.

Also for debugging the app bundle should be part of the build nopt the deployment
When was the last time that there was a working OSX build?  Is the Windows version build from the autotools files or is it a separately maintained set of MS Visual Code files?

prissi

All releases are built from autotools.

The last working version I had, was a PPC Mac version, running from commandline. But the bundle is more recent, from 2017 or so, when there were still PPC/Intel dual releases.

The current nightly is built on github, since this is the only way to access a Mac for any of the active developers.

QuoteEverything that is needed to start must be inside the bundle.
What you mean by bundle? I am not really familiar with MacOS terminology. Do you mean that game content should be in some other Lbrary folder, in priciple, like for Debian too.

mark1878

No a Bundle is a directory with a particular extension e.g. .app or .bundle or several others. Which in MacOs the user sees as one thing.

For example a program is a .app directory, which is installed by dragging one thing to /Applications.  Consider it is like a zip file that the user does not ever unzip, they just copy or run it , the code in the program knows how to navigate it. In detail the code just manipulates files so the same C code can still be used.

Thus everything has to be in that one directory and be read only.

When the app starts if it needs to write to this data it has to acquire a known place to write to - you have chosen ~/Library/Simutrans (which is OK but a bit early 2000 development choice and might need to be changed to fit Apple sandboxing requirements if you want to distribute via Steam). If the data supplied by the app can be edited then it needs to be copied from the app bundle to this directory. For more see https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19

If you have no Mac developers I would ask how many Mac users have you got and is it worth the effort to make the system run?

Another issue I saw is that I got a runtime comment that Simutrans is better as a 32 bit executable - that is a big problem as macOs now (from Catalina released last year) only supports 64 bit executables.

Given these points is it worth attempting a mac port. I think I could do it but then how will the simutrans developers be able to support it?


Roboron

I have set up a Mac VM to try and get the Mac version running for Steam, and followed CannonBall's instructions:

Quote from: CannonBall7 on October 14, 2020, 10:17:13 PM- install build dependencies from Homebrew (https://brew.sh):
  brew install autoconf automake freetype libpng pkg-config sdl2
- compile:
  autoreconf -ivf
  ./configure CC=clang
  make BACKEND=sdl2 MULTI_THREAD=1 OPTIMISE=1 OSTYPE=mac USE_FREETYPE=1 USE_UPNP=0 USE_ZSTD=0 AV_FOUNDATION=1
  make OSX/getversion
- build app and compress for distribution:
  ./distribute.sh

Now I can open Simutrans (it will crash unless I disable MIDI, but that's a problem for another day), but only if I have the libraries installed from brew. If I uninstall the libraries, I get:

Quotedyld: Library not loaded: @rpath/../Frameworks/libfreetype.6.dylib

My experience with linux's rpath (and what I've read online so far) tells me that this rpath is ok, but obviously something is wrong. I have tried workarounding this issue adding an @executable_path. It then loads freetype.lib, but freetype.lib asks for /usr/local/opt/libpng/libpng16.16.dylib instead of looking in just the same directory it is! I cant' do the same for libfreetype, so I'm stuck again.

I will try to continue tomorrow.

Btw, nitghly builds are not working (again).

mark1878

#18
The nightly build for 11th October seems OK. I don't have the brew libraries installed (I use macports which puts them in a different place) so the executable can't be finding them



Actually the nightly build seems not to have used the command line you give. otool -L simutrans says it only has SDL2 as a third party library and was build with QTKit not AVFoundation

otool on a Mojave machine says

otool -L simutrans.app/Contents/MacOS/simutrans                                             
simutrans.app/Contents/MacOS/simutrans:
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
   /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.17.0)
   /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0)
   @rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 8.0.0)
   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
   /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0)
   /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)


And it works on my machine as I have SDL2.framework from 2016 in my ~/Library/Frameworks and copying that to Contents/Frameworks - works.

The nightly build must have been from before the distribute.sh changes as it did not have the Frameworks directory

OK I now read the whole thread and see we are back to reply $5 and the reason to change is the github build as github cannot load the SDL2.framework.

Can we do the old way of using third party libraries and put a copy of the SDL2 framework in our version control?

mark1878

OK I am now really confused and probably confusing others.

I must have used the Sourceforge release of October 11 which runs as I have SDL2.framework installed.

My comments on bundles still apply - which are needed for Steam and proper macOS support.

Is there a nightly build available - and if so where.
Similarly all these github actions where are these run and where can we see th logs and the produced artifacts





Roboron

#20
Nightlies are released on https://nightly.simutrans.com/es/ . There's no current nightly, but you can download an older version from 18th october, which was compiled with freetype support with the changes proposed previously by CannonBall. If you try to run it, you will probably run into the very same problem as me.

EDIT: direct link to last nightly https://nightly.simutrans.com/download.php?os=Mac&r=9303

mark1878

Oh it is worse - I am on Mojave - macOS 10.14.6 The app says I need macOS 10.15 (Catalina) or later.

I can confirm that the freetype issue is there. otool -L shows
   /usr/local/opt/freetype/lib/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.2.0)

For now do we really need freetype - if not then build without it.
Then I think from reading the github action  there are two bugs with the github build of January (ie no need to install_name_tool)
1) SDL2.framework needs to be copied into the app bundle
2) Fix the macOS version needed - this should be possible by the correct compile flags but I need to study them as I  only build for myself now and I don't know if github builds support this.

prissi

#22
There are two MacOS environment on Github.
macOS Big Sur 11.0
macOS Catalina 10.15
I can happily switch to MacOS 11.x

Also I need more instruction what works and what not. If I read correctly, I should revert the change to the MacOS runn on the 11th?

The newer builds have a framework folder with dylibs. Please download from here: https://github.com/aburch/simutrans/releases/download/Nightly/simumac-nightly.zip

I set the build OS now to 11.0. Maybe this shoudl solve the compatibility issue. Please download form above in about six hours from now (about evening in Europe)

Roboron

Quote from: Roboron on October 24, 2020, 01:59:37 AMI cant' do the same for libfreetype

Actually, I can, I just needed to use sudo (lol). Now I have a self-contained Mac OS simutrans.

Quoteotool -L simutrans.app/Contents/MacOS/simutrans
simutrans.app/Contents/MacOS/simutrans:
   @executable_path/../Frameworks/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.4.0)
   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
   /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
   @executable_path/../Frameworks/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1677.104.0)
   /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
   @executable_path/../Frameworks/libSDL2-2.0.0.dylib (compatibility version 13.0.0, current version 13.0.0)
   /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
   /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
   /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
   /System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)
   /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
   /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
   /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
   /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 162.0.0)
   /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
   /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0, weak)
   /System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 212.8.0, weak)
   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
   /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)

A link: https://michan.noho.st/nextcloud/s/gKaP2BarHoKwWRT

Unfortunately, this has been compiled on my VM running macOS Big Sur 11.0, so it may not work on previous versions.

Attached there is the patch with necessary changes to ./distribute.sh for this to work, so GitHub Actions can take care of other macOS versions.

Now, time to test it on Steam.

Roboron

It works! No more modifications needed. Simutrans on Steam is back on Mac :_D


mark1878

Unfortunately fails for me with error


Termination Reason:    DYLD, [0x4] Symbol missing

Dyld Error Message:
  Symbol not found: _objc_opt_respondsToSelector
  Referenced from: /Users/USER/Library/Application Support/Steam/*/simutrans.app/Contents/MacOS/../Frameworks/libSDL2-2.0.0.dylib (which was built for Mac OS X 10.15)
  Expected in: /usr/lib/libobjc.A.dylib

I am on macOS 10.14.6

I think this is because brew builds for the current OS and on github this is 10.15

However well done Roboron.

I will still try the old framework build to work as it is built with minimum version of 10.6 (a bit excessive but we will see)


prissi

Thanks, I try this for the normal build too.

By the way, the current SImutrans gets also a paksetinstaller for all other OS (including MacOS), if the target OS allows writing to the target dir,

Roboron

Quote from: mark1878 on October 24, 2020, 01:54:53 PMI am on macOS 10.14.6

I think this is because brew builds for the current OS and on github this is 10.15

This is a difficult situation to solve. We can't target every version of macOS, specially if the build system (and me) only have access to 10.15/11.0 :/
I would like to provide more support for older versions on Steam, but in this situation the only thing I can do is to target the lastest macOS versions and let the users know that no official support will be available for any other version that is not the last one.

However, if you (or any other mac user) want to provide a build for older versions, follow CannonBall's instructions (my fix for the linked libraries is now incorporated on the svn), and provide me with the simutrans.app, so I can publish it as an additional branch.

prissi

This thread became quite messz. Anzwaz, please MacOS user test also the latest MacOS nightly, if it works (and maybe even install pakset). It shoudl work with any OS newer than 11.0

Roboron

Quote from: prissi on October 25, 2020, 11:38:11 AMplease MacOS user test also the latest MacOS nightly,

There is no new nightly at https://nightly.simutrans.com/ . Is something wrong with the build system? (logs?).

THLeaderH

Thank you for the work to support macOS!
I tested the app binary that Roboron provided at yesterday 11:33:43, and got the following error.


dyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2
  Referenced from: /Users/THLeaderH/Downloads/simutrans-1/simutrans.app/Contents/MacOS/simutrans
  Reason: image not found


The version of my mac is 10.15.7.


EDIT: Woops, I used the older version. I tested one that Roboron provided at yesterday 12:40:43 PM and it works!
However, the app files works when I launched from the command line, but it fails when I launched with double click. I'm seeing why it happens.

Roboron

Quote from: THLeaderH on October 25, 2020, 11:55:11 AMdyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2

This is a contradiction! See the previous logs by me and mark, "@rpath..." should be replaced by "@executable_path/../Frameworks/libSDL2-2.0.0.dylib".

Are you sure you did not accidentally open a previous version? (or maybe I zipped a wrong version).

If so, what's the output of "otool -L simutrans.app/Contents/MacOS/simutrans "?

THLeaderH

#32
The binary was successfully launched when I executed simutrans.app/Contents/MacOS/simutrans, but immediately exited without any crash logs when I double clicked simutrans.app.

The result of "otool -L simutrans.app/Contents/MacOS/simutrans " is as follows.

@executable_path/../Frameworks/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.4.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
@executable_path/../Frameworks/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1677.104.0)
/System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
@executable_path/../Frameworks/libSDL2-2.0.0.dylib (compatibility version 13.0.0, current version 13.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
/System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 162.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0, weak)
/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 212.8.0, weak)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)


UPDATE: I tried the double clicking of the app file in the environment that Roboron provided and got immediate crash. However, once I copied the app file to the existing environment that I use for my daily play, and the app was successfully launched. I'm seeing what is the difference, but I've not found the cause of this phenomenon.
I also got the immediate crash with the command "open -a simutrans.app"

Roboron

Quote from: THLeaderH on October 25, 2020, 12:14:20 PMThe binary was successfully launched when I executed simutrans.app/Contents/MacOS/simutrans, but immediately exited without any crash logs when I double clicked simutrans.app.

Weird. I don't have this issue. What happens when you execute "open simutrans.app"?

THLeaderH

In Roboron's environment, I got immediate crash without any logs with "open simutrans.app". There are no error logs in console.app.