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

macOS: Build x86_64h slice #2982

Merged
merged 1 commit into from Oct 3, 2017

Conversation

Projects
None yet
4 participants
@MerryMage
Copy link
Member

MerryMage commented Oct 2, 2017

This commit produces a fat-binary with two slices. The x86_64 slice
is for all x64 systems, and the x86_64h slice targets x64 systems
starting with Haswell. The latter allows the compiler to use newer
instructions that are not available on older microarchitectures.


This change is Reviewable

@bunnei

bunnei approved these changes Oct 2, 2017

@B3n30

This comment has been minimized.

Copy link
Contributor

B3n30 commented Oct 2, 2017

I didn't test this PR but with my latest test xcode compiled the code a lot better compared to make(gcc?). Isn't it possible to build with xcode for haswell?

I also can't test the compile for haswell, since my OSX hasn't got one

@jroweboy

This comment has been minimized.

Copy link
Member

jroweboy commented Oct 2, 2017

Couple of quick questions before I click that green merge button. Whats the size difference after this change? (Should be no more than a few extra MB right?) Have you double checked that this doesn't break anything with our custom post build deploy steps? (I'm guessing this isn't an issue, but its worth checking before clicking merge and I don't have a mac or I woulda done it myself)

macOS: Build x86_64h slice
This commit produces a fat-binary with two slices. The x86_64 slice
is for all x64 systems, and the x86_64h slice targets x64 systems
starting with Haswell. The latter allows the compiler to use newer
instructions that are not available on older microarchitectures.

@MerryMage MerryMage force-pushed the MerryMage:lazy-macos-opt branch from 150289e to 29a6fba Oct 2, 2017

@MerryMage

This comment has been minimized.

Copy link
Member

MerryMage commented Oct 2, 2017

xcode compiled the code a lot better compared to make(gcc?).

They should be using the same compiler. You can see this by running /Applications/Xcode.app/Contents/Developer/usr/bin/g++ --version, which would show it's really just clang and not gcc.

Whats the size difference after this change? (Should be no more than a few extra MB right?)

Double binary size. Libraries remain the same size. A few extra MB. (Size of final .tar.gz: 17 MB vs 13 MB.)

Have you double checked that this doesn't break anything with our custom post build deploy steps?

Tried it, paths changed, fixed that.

@B3n30

This comment has been minimized.

Copy link
Contributor

B3n30 commented Oct 2, 2017

without GXcode:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
with GXcode:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++

Sorry you are right

@MerryMage

This comment has been minimized.

Copy link
Member

MerryMage commented Oct 2, 2017

@B3n30

Sure, but c++ is just an alias of clang++.

$ ls -la c++
lrwxr-xr-x  1 root  wheel  5 20 Mar  2017 c++ -> clang
@B3n30

B3n30 approved these changes Oct 2, 2017

@jroweboy jroweboy merged commit 26629c6 into citra-emu:master Oct 3, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@MerryMage MerryMage deleted the MerryMage:lazy-macos-opt branch Oct 3, 2017

@FearlessTobi FearlessTobi referenced this pull request Jan 16, 2018

Closed

Things that should be ported over from Citra #40

34 of 35 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment