Page 3 of 6
Re: Current state of Mac version?
Posted: Wed Jan 12, 2022 12:46 pm
by hiran
Commander_X wrote: ↑Wed Jan 12, 2022 6:19 am
hiran wrote: ↑Tue Jan 11, 2022 9:24 pm
[...]
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
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...
Re: Current state of Mac version?
Posted: Wed Jan 12, 2022 12:55 pm
by another_commander
The asm directives are in the source code for Spidermonkey, which the Mac project tries to build before anything else.
Re: Current state of Mac version?
Posted: Wed Jan 12, 2022 5:05 pm
by hiran
another_commander wrote: ↑Wed Jan 12, 2022 12:55 pm
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?
Re: Current state of Mac version?
Posted: Wed Jan 12, 2022 8:14 pm
by Commander_X
hiran wrote: ↑Wed Jan 12, 2022 5:05 pm
[...]
@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).
Re: Current state of Mac version?
Posted: Wed Jan 12, 2022 8:19 pm
by hiran
Commander_X wrote: ↑Wed Jan 12, 2022 8:14 pm
hiran wrote: ↑Wed Jan 12, 2022 5:05 pm
[...]
@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
Re: Current state of Mac version?
Posted: Thu Jan 13, 2022 6:37 am
by 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.
Re: Current state of Mac version?
Posted: Thu Jan 13, 2022 9:01 pm
by 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.
Re: Current state of Mac version?
Posted: Thu Jan 13, 2022 11:01 pm
by phkb
@Commander_X: What version of MacOS and Xcode do you have in your VM?
Re: Current state of Mac version?
Posted: Fri Jan 14, 2022 12:33 am
by Commander_X
phkb wrote: ↑Thu Jan 13, 2022 11:01 pm
@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
%
Re: Current state of Mac version?
Posted: Fri Jan 14, 2022 8:24 am
by hiran
Commander_X wrote: ↑Thu Jan 13, 2022 9:01 pm
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.
Re: Current state of Mac version?
Posted: Fri Jan 14, 2022 11:37 am
by 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...
Re: Current state of Mac version?
Posted: Fri Jan 14, 2022 1:55 pm
by Commander_X
hiran wrote: ↑Fri Jan 14, 2022 11:37 am
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.
Re: Current state of Mac version?
Posted: Fri Jan 14, 2022 2:52 pm
by hiran
Commander_X wrote: ↑Fri Jan 14, 2022 1:55 pm
hiran wrote: ↑Fri Jan 14, 2022 11:37 am
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.
Re: Current state of Mac version?
Posted: Fri Jan 14, 2022 3:07 pm
by Commander_X
hiran wrote: ↑Fri Jan 14, 2022 2:52 pm
[...]
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.
Re: Current state of Mac version?
Posted: Fri Jan 14, 2022 8:30 pm
by hiran
Commander_X wrote: ↑Fri Jan 14, 2022 3:07 pm
hiran wrote: ↑Fri Jan 14, 2022 2:52 pm
[...]
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?