Current state of Mac version?

[hiran]

[...]

Code: Select all

error: meaningless 'volatile' on asm outside function

[...]

In my build attempt ("visual" Xcode), the environment suggested to get rid of the 'volatile' keyword, which, after performing (I think there were 3 occurrences) continued the compilation.
Again, the resulting application, didn't run, unfortunately.

In which files did you remove that keyword actually? When I grep my clone of oolite I cannot find any. Likewise when I clone the oolite-mac-components.

Or could that be connected to the fact that in Github the Mac-specific directory is rendered as

Code: Select all

Mac-specific @ 90eb952 

which results in workflow output

Code: Select all

  From https://github.com/OoliteProject/oolite-mac-components
   * branch            90eb952576bc41b8c1751a70bfcecb470a1e6db5 -> FETCH_HEAD

which indicates we must not look for the master/head revision. But where is that information stored? It is not in .gitmodules but somewhere it must be...

[another_commander]

The asm directives are in the source code for Spidermonkey, which the Mac project tries to build before anything else.

[hiran]

The asm directives are in the source code for Spidermonkey, which the Mac project tries to build before anything else.

Ok, I checked the spidermonkey repository. And I see 26 occurrences, which is definitely more than ~3. Would not all of them have to go?

Code: Select all

egrep -r "asm\s+volatile\s" *
js/src/ctypes/libffi/testsuite/libffi.call/closure_stdcall.c:  asm volatile (" movl %%esp,%0" : "=g" (sp_pre));
js/src/ctypes/libffi/testsuite/libffi.call/closure_stdcall.c:  asm volatile (" movl %%esp,%0" : "=g" (sp_post));
js/src/ctypes/libffi/src/sparc/ffi.c:  asm volatile ("flush	%0" : : "r" (closure) : "memory");
js/src/ctypes/libffi/src/sparc/ffi.c:  asm volatile ("flush	%0" : : "r" (((char *) closure) + 8) : "memory");
js/src/ctypes/libffi/src/sparc/ffi.c:  asm volatile ("iflush	%0" : : "r" (closure) : "memory");
js/src/ctypes/libffi/src/sparc/ffi.c:  asm volatile ("iflush	%0" : : "r" (((char *) closure) + 8) : "memory");
js/src/ctypes/libffi/src/sh64/ffi.c:  asm volatile ("ocbwb %0,0; synco; icbi %1,0; synci" : : "r" (tramp),
js/src/ctypes/libffi/src/alpha/ffi.c:  asm volatile ("call_pal 0x86" : : : "memory");
js/src/assembler/jit/ExecutableAllocator.h:        asm volatile (
js/src/assembler/jit/ExecutableAllocator.h:        asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
js/src/methodjit/MethodJIT.cpp:asm volatile (
nsprpub/pr/src/md/windows/ntmisc.c:  asm volatile ("lock ; xadd %0, %1" 
nsprpub/pr/src/md/windows/ntmisc.c:  asm volatile ("lock ; xadd %0, %1" 
nsprpub/pr/src/md/windows/ntmisc.c:  asm volatile ("lock ; xadd %0, %1" 

@Commander_X: It seems you have a Mac and can compile locally. Could you investigate a bit what we need to change to get to a running build?
You say your build actually finished but the result was unusable. What did you run, and what did you perceive when running it?

[Commander_X]

[...]
@Commander_X: It seems you have a Mac and can compile locally. Could you investigate a bit what we need to change to get to a running build?
You say your build actually finished but the result was unusable. What did you run, and what did you perceive when running it?

I have a Mac VM.
As I mentioned, i've used the "Visual" part of Xcode to compile (that is, how you'd open the "project" file in an IDE and run the compile from there).
I will try a console "xcodebuild" approach, it may take a while, though.
From what I recall, a major issue were the older Mac OS versions used as targets in the project file(s) (they're not supported -- I'd guess easily -- in the latest and greatest of Xcode).

[hiran]

[...]
@Commander_X: It seems you have a Mac and can compile locally. Could you investigate a bit what we need to change to get to a running build?
You say your build actually finished but the result was unusable. What did you run, and what did you perceive when running it?

I have a Mac VM.
As I mentioned, i've used the "Visual" part of Xcode to compile (that is, how you'd open the "project" file in an IDE and run the compile from there).
I will try a console "xcodebuild" approach, it may take a while, though.
From what I recall, a major issue were the older Mac OS versions used as targets in the project file(s) (they're not supported -- I'd guess easily -- in the latest and greatest of Xcode).

You are right. I received a number of warnings about that, and I got rid of them with this change:
https://github.com/HiranChaudhuri/oolit ... 18c37b585d

[hiran]

I small step ahead. I finally got around the 'meaningless volatile' error by removing the volatile keywords and make that build run on Github.
The next errors I am facing is

Code: Select all

/Users/runner/work/oolite/oolite/Mac-specific/Oolite-docktile/OODockTilePlugIn.m:238:19: error: 'DetermineIfPathIsEnclosedByFolder' is deprecated: first deprecated in macOS 10.8 [-Werror,-Wdeprecated-declarations]
                        OSStatus err = DetermineIfPathIsEnclosedByFolder(kOnAppropriateDisk, kTrashFolderType, utfPath, false, &inTrash);

Unfortunately I could not find any hint of what may be a replacement function for newer MacOS releases.
https://developer.apple.com/documentati ... sedbyfolde

Code: Select all

 /Users/runner/work/oolite/oolite/Mac-specific/Oolite-docktile/OODockTilePlugIn.m:57:13: error: 'loadNibNamed:owner:' is deprecated: first deprecated in macOS 10.8 [-Werror,-Wdeprecated-declarations]
                [NSBundle loadNibNamed:@"OODockTilePlugIn" owner:self];

I have not investigated into the loadNibNamed at all.

[Commander_X]

Ok, I succeeded to do a '** BUILD SUCCEEDED **' command line only execution, with the same result mentioned earlier (the app won't start).

Here would be the steps I've taken, after getting a fresh clone and submodules from github:
- xcodebuild -configuration "TestRelease" MACOSX_DEPLOYMENT_TARGET=10.9
- first hit, as mentioned, "asm volatile"
sed -i ".sed" -e "s/asm\ volatile/asm/g" deps/mozilla/js/src/methodjit/MethodJIT.cpp
- secondly the deprecated declarations (8 errors) -- to avoid, I ran:
xcodebuild -configuration "TestRelease" MACOSX_DEPLOYMENT_TARGET=10.9 OTHER_CFLAGS="-Wno-deprecated-declarations"

The build succeeded, when trying to run, the application will show the splash, and over it there will be a message box saying:
"Oolite failed to start up, because an unhandled exception occurred.
An exception of type NSInvalidArgumentException occurred. If this problem persists, please file a bug report."
Clicking OK closes the application.

Besides the log header, the dated entries in the log are:

Code: Select all

15:53:03.737 [dataCache.rebuild]: Data cache version (1.90) does not match Oolite version (1.91), rebuilding cache.
15:53:04.372 [startup.exception]: ***** Unhandled exception during startup: NSInvalidArgumentException (*** +[NSString stringWithUTF8String:]: NULL cString).

Closing log at 2022-01-13 20:57:17 +0000.

[phkb]

@Commander_X: What version of MacOS and Xcode do you have in your VM?

[Commander_X]

@Commander_X: What version of MacOS and Xcode do you have in your VM?

Code: Select all

% sw_vers 
ProductName:	macOS
ProductVersion:	11.6.2
BuildVersion:	20G314
% xcodebuild -version
Xcode 13.2.1
Build version 13C100
%

[hiran]

Ok, I succeeded to do a '** BUILD SUCCEEDED **' command line only execution, with the same result mentioned earlier (the app won't start).

Here would be the steps I've taken, after getting a fresh clone and submodules from github:
- xcodebuild -configuration "TestRelease" MACOSX_DEPLOYMENT_TARGET=10.9
- first hit, as mentioned, "asm volatile"
sed -i ".sed" -e "s/asm\ volatile/asm/g" deps/mozilla/js/src/methodjit/MethodJIT.cpp
- secondly the deprecated declarations (8 errors) -- to avoid, I ran:
xcodebuild -configuration "TestRelease" MACOSX_DEPLOYMENT_TARGET=10.9 OTHER_CFLAGS="-Wno-deprecated-declarations"

The build succeeded, when trying to run, the application will show the splash, and over it there will be a message box saying:
"Oolite failed to start up, because an unhandled exception occurred.
An exception of type NSInvalidArgumentException occurred. If this problem persists, please file a bug report."
Clicking OK closes the application.

Besides the log header, the dated entries in the log are:

Code: Select all

15:53:03.737 [dataCache.rebuild]: Data cache version (1.90) does not match Oolite version (1.91), rebuilding cache.
15:53:04.372 [startup.exception]: ***** Unhandled exception during startup: NSInvalidArgumentException (*** +[NSString stringWithUTF8String:]: NULL cString).

Closing log at 2022-01-13 20:57:17 +0000.

Thank you for working that out. The command
xcodebuild -configuration "TestRelease" MACOSX_DEPLOYMENT_TARGET=10.9 OTHER_CFLAGS="-Wno-deprecated-declarations"
also gave me a "BUILD SUCCEEDED" -> https://github.com/HiranChaudhuri/oolit ... focus=true

Running tests automatically did not work, and I do not have a machine for testing. But at least I can try to create a release for others to test.
Where would I find the relevant output files?

The runtime error you describe should at least have placed some more information into the logfile - but that is to be investigated by someone in control of the source code.

[hiran]

Finally I was able to create a zip file: https://github.com/HiranChaudhuri/oolite/releases

There is no guarantee this zip contains the required files.
There is no guarantee this zip contains a runnable version of Oolite.

But as I have no way to verify please let me know what needs to be changed, and if you can also let me what to change it into...

[Commander_X]

Finally I was able to create a zip file: https://github.com/HiranChaudhuri/oolite/releases
[...]

It doesn't launch, it returns a message box with ""Oolite.app" is damaged and can't be opened. You should move it to Trash. Firefox downloaded this file today at [...] from github.com" with two buttons "Move to Trash" and "Cancel".
You packaged (zipped) the whole TestRelease folder from your build, but you'd only need to do that for the Oolite.app folder.

Other than the manual change you've made to the Info.plist file, all the text diffs I can see are about versions and hashes.

Several other statistics:
- files that differ in Oolite.app: 26
- no. of files I have in Oolite.app/yours: 585/772
- no. of files I have in TestRelease/yours: 653/840
- it seems that the main differences in Oolite.app occurred due to what was pushed from Sparkle.framework

EDIT:
Actually the above proves I'm not a day-by-day Mac user.
Besides the file differences, "your" build reproduces what I mentioned about what happened with "mine".

Warning for the users of more recent macOS: unzipping a file downloaded from internet will place its extracted contents in quarantine, you'll need to get rid of it in order to run/use it.

[hiran]

Finally I was able to create a zip file: https://github.com/HiranChaudhuri/oolite/releases
[...]

It doesn't launch, it returns a message box with ""Oolite.app" is damaged and can't be opened. You should move it to Trash. Firefox downloaded this file today at [...] from github.com" with two buttons "Move to Trash" and "Cancel".
You packaged (zipped) the whole TestRelease folder from your build, but you'd only need to do that for the Oolite.app folder.

Other than the manual change you've made to the Info.plist file, all the text diffs I can see are about versions and hashes.

Several other statistics:
- files that differ in Oolite.app: 26
- no. of files I have in Oolite.app/yours: 585/772
- no. of files I have in TestRelease/yours: 653/840
- it seems that the main differences in Oolite.app occurred due to what was pushed from Sparkle.framework

EDIT:
Actually the above proves I'm not a day-by-day Mac user.
Besides the file differences, "your" build reproduces what I mentioned about what happened with "mine".

Warning for the users of more recent macOS: unzipping a file downloaded from internet will place its extracted contents in quarantine, you'll need to get rid of it in order to run/use it.

Thank you for the verification. It seems the status is worse than I thought. Somehow I assumed the file could at least be successfully extracted.

To reduce the amount of files in the zip I already changed the workflow but it failed and left me scratching my head.
For the other differences: There can be lots regarding the OS, the installed IDE or libraries etc etc. so I'd not be wondering too much.

Somehow I had to libpng, I changed the seamonkey repository to get rid of the erroring "meaningless volatile"s, but then I added your build options to get around the deprecation warnings.
Finally I had to make up my mind what to place inside the release zip as it seems the xcode build process did not create it automatically.

Since you have good knowledge of what you are doing I'd happily accept some guidance where the build can get fixed.

[Commander_X]

[...]
Finally I had to make up my mind what to place inside the release zip as it seems the xcode build process did not create it automatically.

Since you have good knowledge of what you are doing I'd happily accept some guidance where the build can get fixed.

As "documented" above, my knowledge is not the most ... reliable

I am not sure how you packaged/zipped the file, but, again, instead of pointing the archiving process to the TestRelease folder, you should've pointed it to the Oolite.app folder inside it.

Definitely, someone with way more knowledge and skills should try to figure out what needs to be done to fix the error(s) with the current build result (i.e. the initial unhandled exception above). The offending stringWithUTF8String call is present in 15 files across the src tree, out of which 14 are in the Core, and 1 in SDL (I'd guess this could be discarded for the Mac build).

EDIT:
It could also be that the "creative" way the js compilation was fixed (asm volatile -> asm) is not the best way to do that.

[hiran]

[...]
Finally I had to make up my mind what to place inside the release zip as it seems the xcode build process did not create it automatically.

Since you have good knowledge of what you are doing I'd happily accept some guidance where the build can get fixed.

As "documented" above, my knowledge is not the most ... reliable

I am not sure how you packaged/zipped the file, but, again, instead of pointing the archiving process to the TestRelease folder, you should've pointed it to the Oolite.app folder inside it.

Definitely, someone with way more knowledge and skills should try to figure out what needs to be done to fix the error(s) with the current build result (i.e. the initial unhandled exception above). The offending stringWithUTF8String call is present in 15 files across the src tree, out of which 14 are in the Core, and 1 in SDL (I'd guess this could be discarded for the Mac build).

EDIT:
It could also be that the "creative" way the js compilation was fixed (asm volatile -> asm) is not the best way to do that.

You can see how I tried the build here:
https://github.com/HiranChaudhuri/oolit ... ld-mac.yml

The surprising bit for me was that zipping just the Oolite.app folder actually failed.
https://github.com/HiranChaudhuri/oolit ... focus=true

Maybe you can try similar commands on your VM and investigate better than I can on the emphemeral runner?