Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch Mac build from 32 to 64 bit #1585

Closed
wants to merge 1 commit into from

Conversation

@memem359
Copy link
Contributor

commented May 26, 2017

Compile the Mac OSX build from i386 to x86_64.

The other change was to correct a typo in CMakeLists. (BOOST_ALL_NO_LINK does not exist.)

I expect this to fail the Travis (Apple/Clang) build initially, because the current libraries are compiled for i386. This will require the Mac 64 bit libraries made by PR 29 for the FO-SDK.
freeorion/freeorion-sdk#29
The dep folder (with static libraries, frameworks, and includes) will need to be copied to the FO build (inside the Xcode folder), along with this PR to switch the Apple/Clang code to 64 bit.

As a side effect, getting some of the -fvisibility=hidden issues straightened out (between the FO code and the SDK) should mean fewer warnings during the client build linking (dozens instead of hundreds).

@dbenage-cx

This comment has been minimized.

Copy link
Member

commented May 26, 2017

@memem359 Thank you for looking into this.
Using 10.12.5, was able to compile and run with linked SDK PR (looking at ~320 warnings, but not been successful in earlier brief attempts)

@memem359

This comment has been minimized.

Copy link
Contributor Author

commented May 26, 2017

@dbenage-cx
Thanks for the reply.
I do have a forum thread open, although not much there now.
http://www.freeorion.org/forum/viewtopic.php?f=4&t=10569
I suspect we will have to go into some details to figure out why we are getting different number of compile warnings.

I can only state what I've been seeing:

  • After visibility=hidden was turned on for the Mac FO build (but not the SDK) some weeks ago, the warnings in the Travis checks jumped to many hundreds (mostly from Boost calls).
  • After using CMake with the SDK PR, and Xcode with this PR, I saw a grand total of 128 issues spread across 6 targets, and at least some of those were semantic warnings (adding parentheses to verify which order the programmer wanted for operators).
  • The SDK xcodeproj generated by the SDK CMake is not useful. For example, the -fvisibility=hidden flag is not present in the Custom Compiler Flags.
@dbenage-cx

This comment has been minimized.

Copy link
Member

commented May 27, 2017

I will try to transfer those build logs over for comparison once I can access them (assuming I can find where/if they are kept).

@memem359

This comment has been minimized.

Copy link
Contributor Author

commented May 27, 2017

Maybe it will be easier if I can replicate what you are seeing (instead of the other way around).
For each part of the build (SDK, then FO):

  1. Did you use CMake or Xcode?
  2. If you used CMake, how did you call it (what arguments on the command line)?
@dbenage-cx

This comment has been minimized.

Copy link
Member

commented May 27, 2017

SDK per README: (cmake --build . --config RelWithDebInfo),
FO: XCode (initially per wiki instructions. later with manual extraction of SDK dep)

I will try to spend some time on reducing the warnings tonight and post to forum, many are for different os version.
logs.tar.gz

@memem359

This comment has been minimized.

Copy link
Contributor Author

commented May 27, 2017

I was thinking about the SDK step before that.

The README has cmake .. to get everything set up before the build.
I added a comment to the README to use instead
cmake -G Xcode -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk ..
(or whatever path is appropriate) for a Mac system, since that is the command that the Travis check uses.

@dbenage-cx

This comment has been minimized.

Copy link
Member

commented May 28, 2017

I missed that change, using the updated args the number of warnings is reduced to 128 👍

@dbenage-cx dbenage-cx added this to the v0.4.8 milestone May 29, 2017

@memem359 memem359 force-pushed the memem359:mac-x86 branch from 405490a to bea72a9 Jun 9, 2017

@memem359

This comment has been minimized.

Copy link
Contributor Author

commented Jun 9, 2017

Updated the PR. Only change is the Xcode project file.

Changing build from i386 to x86_64.
Switching the Boost libraries from static to shared has fixed the problem with the Logger.
About a dozen Boost preprocessor macros are now being used, which is needed to straighten out symbol visibility=hidden issues with the Boost include file definitions. (When the Travis CI build is run with the new libraries and these options, there will be several dozen warnings during the build instead of the previous several hundred.)

To remind people, the Travis check will fail, unless the new "dep" file from SDK PR 29 is used.
(That PR has already been updated.)

@geoffthemedio

This comment has been minimized.

Copy link
Member

commented Jun 10, 2017

Probably worth doing this fairly soon... Read something yesrerday about OSX new versions or patches no longer supporting 32 bit applications.

@Vezzra

This comment has been minimized.

Copy link
Member

commented Jun 11, 2017

@geoffthemedio, can you provide a link to the source of that information? That sounds like a very drastic step, AFAICT there are still quite some 32bit apps for OSX out there...

EDIT: Did some quick googling, turned up infos that 32bit support is apparently going to be dropped for iOS. Saw no mention of OSX/macOS.

@LGM-Doyle

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2017

I'm checking to see if this PR and also freeorion/freeorion-sdk#29 are still progressing?
Have any of the OSX devs checked that they are working and an improvement on the current linker difficulties?

@Vezzra

This comment has been minimized.

Copy link
Member

commented Jul 9, 2017

It's on my list, but I'm corrently struggling with RL issues, see also my comment here.

Sorry for dropping the ball on you guys... 😞

@memem359 memem359 force-pushed the memem359:mac-x86 branch from bea72a9 to 8518a94 Sep 2, 2017

@memem359

This comment has been minimized.

Copy link
Contributor Author

commented Sep 2, 2017

I just did a rebase to master.
(There were 3 changes to the xcodeproj file since June, so those changes had to be resolved.)

The situation is mostly the same as my June 9th note.
This build will require the libraries from the SDK PR. The SDK available from the web page will need to be modified and the change mentioned.
(Those will also have to be added to the travis-ci in order for that compile test to work.)

@LGM-Doyle

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2017

Ping.

Is this PR and also freeorion/freeorion-sdk#29 still progressing?

Would it be less labor intensive to merge the changes into the SDK (perhaps a non-release version) and use it in Travis? If the number of Travis errors reduce and the build succeeds, then we can proceed.

@memem359

This comment has been minimized.

Copy link
Contributor Author

commented Oct 8, 2017

There is no progress.
This PR requires the SDK PR. (Getting the logger to work for the Mac requires the Boost libraries to be shared instead of static.)

That one is stalled due to the request to move a task from the script to Boost, despite the fact that it doesn't seem to be possible (due to problems with that particular version of Boost being used). Despite reporting my problems trying to comply that request, I only received a short response (after months of silence) that it should still be done.

EDIT: Switching Boost to a slightly more recent version might fix the problem. But I don't know if that is an option worth considering. I've just posted an issue ( freeorion/freeorion-sdk#35 ) to ask that question.

@Vezzra

This comment has been minimized.

Copy link
Member

commented Oct 8, 2017

I guess that @adrianbroher didn't have the time to look into the problem why the fix he proposed and obviously prefers doesn't work (he hasn't been around much lately). Which is why progress on all that related issues (new loggers not working and switching to 64 bit on Mac etc.) is currently completely blocked.

Unfortunately RL continues to seriously impact the time I can spend on FO, which is why I failed to get around to look into these issues myself. However, the issues with the logger on Mac are critical and absolutely must be resolved for 0.4.8.

Which means, if all else fails, we might need to resort to a workaround/fix we don't like (because it's messy or whatever). But I'm very much against having a broken logger on OSX in a release, so something is going to happen in the foreseeable future (which means until the end of the year at the latest, hopefully).

@adrianbroher

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2017

Some infodump related to Geoffs note (#1585 (comment))

There is no point in supporting universal binaries on OSX in my opinion. It looks like Apple drops 32-bit applications after High Sierra (10.13) and the las version with 32-bit hardware support is Snow Leopard (10.6) so there only remains x86_64 as architecture for desktop-ish systems for OSX devices.

https://support.apple.com/en-us/HT3770
https://developer.apple.com/library/content/documentation/Darwin/Conceptual/64bitPorting/intro/intro.html
https://developer.apple.com/news/?id=06282017a

@Vezzra

This comment has been minimized.

Copy link
Member

commented Nov 9, 2017

There is no point in supporting universal binaries on OSX in my opinion.

This is absolutely correct. Supporting universal binaries is completely unnecessary, for all the reasons cited.

@Vezzra

This comment has been minimized.

Copy link
Member

commented Nov 9, 2017

Superseded by d4d7bb0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.