Skip to content

Support compiling for earlier releases of macOS #960

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Mar 10, 2023
Merged

Support compiling for earlier releases of macOS #960

merged 2 commits into from
Mar 10, 2023

Conversation

briankendall
Copy link
Contributor

@briankendall briankendall commented Feb 20, 2023 •
edited
Loading

Description

These changes broaden the macOS versions that Sunshine can be compiled for. There are only a few places in the codebase where a macOS API function that requires macOS 10.15 or later is used, and this PR makes it so that these functions are weakly linked and avoids using them when running in macOS 10.14 and earlier.

The other issue with compiling on macOS 10.14 is that its version of libc++ doesn't support some of the later C++ features used throughout the codebase. However, this can be overcome by compiling with a newer installation of LLVM / clang and statically linking against its copy of libc++.

With the changes in this PR, I was able to get Sunshine to compile for macOS 10.12-10.14 by installing clang 15 using MacPorts (along with Sunshine's other dependencies) and then configuring it with the following cmake command:

export CC=/opt/local/libexec/llvm-15/bin/clang
export CXX=/opt/local/libexec/llvm-15/bin/clang++
cmake \
    -DCMAKE_CXX_FLAGS="-nostdinc++ -nostdlib++ -isystem /opt/local/libexec/llvm-15/include/c++/v1 -I /opt/local/include -I /opt/local/libexec/openssl11/include" \
    -DCMAKE_EXE_LINKER_FLAGS="-nostdlib /opt/local/libexec/llvm-15/lib/libc++.a /opt/local/libexec/llvm-15/lib/libc++abi.a /usr/lib/libSystem.dylib" \
    -DBOOST_ROOT=/opt/local/libexec/boost/1.80 \
    -DCMAKE_OSX_DEPLOYMENT_TARGET=10.12 \
    /path/to/sunshine

(Note that I had to manually supply to paths for both boost and OpenSSL.)

Even if Sunshine will perform worse in them than the latest macOS releases, I think it's important to support older releases of macOS at least in some capacity (even if it requires the user to compile it themselves) since it's very useful for them to have a fully open source streaming solution, as well as there being a lot of reasons to avoid the newer releases of macOS, including lack of support for older macs, poorer options for customization, Apple's continuing agenda of removing user control, and them just generally being frustratingly buggy.

Personally I'm still running macOS 10.14 and have no intention of updating any time soon, if I can manage it! And I'd still like to use Sunshine if I can.

Screenshot

N/A

Issues Fixed or Closed

N/A

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Dependency update (updates to dependencies)
  • Documentation update (changes to documentation)
  • Repository update (changes to repository files, e.g. .github/...)

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

  • I want maintainers to keep my branch updated

@github-actions
Copy link

Your PR was set to master, PRs should be sent to nightly.
The base branch of this PR has been automatically changed to nightly.
Please check that there are no merge conflicts

@github-actions github-actions bot changed the base branch from master to nightly February 20, 2023 04:25
@ReenigneArcher
Copy link
Member

Thank you for this PR! While we cannot build older version in our CI (https://github.blog/changelog/2022-07-20-github-actions-the-macos-10-15-actions-runner-image-is-being-deprecated-and-will-be-removed-by-8-30-22/) I do think it's good to have support for older hardware in some capacity.

P.S. Do you have any thoughts about statically linking deps during the macOS build? I think it would solve the issues we have with the pkg and dmg packages.

@ReenigneArcher ReenigneArcher requested a review from a team February 21, 2023 14:24
@briankendall
Copy link
Contributor Author

P.S. Do you have any thoughts about statically linking deps during the macOS build? I think it would solve the issues we have with the pkg and dmg packages.

There's nothing wrong with using static linking to smooth out installation. The norm in macOS is to include all of the necessary binaries for an app or package in one way or another, rather than relying on something like a package manager. Using static linking certainly seems like the shortest route to getting there.

I'll mention that the other more "mac-like" way to do it would be to package Sunshine into an application bundle and then include all of its needed libraries inside of there, generally in the Contents/Frameworks subdirectory. With dependencies coming from a package manager, though, that gets really tricky since Sunshine's dependencies have their own tree of dependencies, and on top of having to gather every single dependency recursively, they'd all have to be altered using a tool like install_name_tool to change the paths referencing every one of those dynamic libraries from absolute paths to bundle-relative ones (so rather than linking to libraries somewhere inside of /opt/local it'd be something like @executable_path/../Frameworks or @rpath). I wonder if there's a tool out there that can do this automatically for binaries compiled using MacPorts or Homebrew?

That all said, my recommendation would still be to use static linking.

With static linking in place, the other thing that would be nice is to have Sunshine be installed into a self-contained location like /Library/Application Support/Sunshine rather than mixing it into /opt/local. I think that could be as simple as changing the default macOS install prefix to /Library/Application Support/Sunshine and then updating its launchd plist to execute it from there.

@ReenigneArcher
Copy link
Member

Could you fix the lint errors please?

@ReenigneArcher ReenigneArcher force-pushed the support-earlier-macos branch from 3d11e00 to 808eb24 Compare March 10, 2023 14:17
ReenigneArcher
ReenigneArcher approved these changes Mar 10, 2023
View reviewed changes
Copy link
Member

@ReenigneArcher ReenigneArcher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't tested this, but the code is well documented and builds fine, so I approve and will merge this.

If you'd be interested in making a PR to statically link the macOS builds it would be really appreciated.

@ReenigneArcher ReenigneArcher merged commit 80aa61b into LizardByte:nightly Mar 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ReenigneArcher ReenigneArcher ReenigneArcher approved these changes

Assignees
No one assigned
Labels
None yet
Projects
No open projects
Sunshine-stack
Status: Done
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@briankendall @ReenigneArcher @LizardByte-bot