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

macOS Build Automation #1250

Closed
rkeene opened this issue Oct 1, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@rkeene
Copy link
Contributor

commented Oct 1, 2018

Verify rpath (collect error from users)
Use SDK for minimum version of macOS we want to support (which is... ?)

@rkeene rkeene added this to the V17.0 milestone Oct 1, 2018

@rkeene rkeene self-assigned this Oct 1, 2018

@argakiig

This comment has been minimized.

Copy link
Collaborator

commented Oct 1, 2018

the rpath can be fixed by using the opensource qt_everywhere installer to get 5.9.x IIRC

@rkeene

This comment has been minimized.

Copy link
Contributor Author

commented Oct 1, 2018

The CMake file tries to set the RPATH but it doesn't seem to work, so need to find out why

@rkeene

This comment has been minimized.

Copy link
Contributor Author

commented Oct 1, 2018

Also related, #1185

@cryptocode

This comment has been minimized.

Copy link
Collaborator

commented Oct 1, 2018

I wonder if https://github.com/nanocurrency/raiblocks/pull/275/files used to be a workaround (but as is, it causes issues in xcode at least, so maybe make it conditional for release?)

@rkeene

This comment has been minimized.

Copy link
Contributor Author

commented Oct 1, 2018

We're going to minimum version of either 10.9 or 10.11, looking into which our userbase cares about

@rkeene

This comment has been minimized.

Copy link
Contributor Author

commented Oct 10, 2018

We're going to support Mac OS X 10.11+ based on the user feedback and considering Apple's support lifecycle.

I looked at the CMake stuff and it only sets the RPATH on the installed files, so it modifies them after installation and I verified it is done correctly. The incorrect part is that each shared object/dynamic library specifies an absolute path to each dependent object. The install_name_tool can update this, but rather than resorting to that we'll just build the version of Qt5 we intend to support as we do with Boost.

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