Skip to content
This repository has been archived by the owner on Nov 21, 2020. It is now read-only.

Bundled dylibs are not linked properly on macOS #63

Closed
McSinyx opened this issue Mar 29, 2020 · 4 comments · Fixed by #92
Closed

Bundled dylibs are not linked properly on macOS #63

McSinyx opened this issue Mar 29, 2020 · 4 comments · Fixed by #92
Labels
blocked Not our fault that this cannot be done (yet) distribution Packaging and distributing of source and binary help wanted Extra attention is needed
Milestone
1.0

Comments

@McSinyx
Copy link
Owner

McSinyx commented Mar 29, 2020 •
edited

I tried to solve it in GH-51 but failed. There are two directions that I can think of:

  1. Continue to find a way to get delocate to be able to bundle the library in @rpath as in my previous attempt.
  2. Package alure2 for Homebrew and install it from there. Edit: this does not magically make the CMake target independent of @rpath.

Either way, I am not familiar with the macOS ecosystem enough to do the job.
@McSinyx McSinyx added help wanted Extra attention is needed distribution Packaging and distributing of source and binary labels Mar 29, 2020
@McSinyx McSinyx added this to the 1.0 milestone Mar 29, 2020
@McSinyx

This comment has been minimized.

Sign in to view
@McSinyx McSinyx mentioned this issue Apr 10, 2020
Merged
@McSinyx McSinyx mentioned this issue Apr 21, 2020
Closed
McSinyx added a commit that referenced this issue Apr 21, 2020
@McSinyx
Update CI/CD
714a14b 
This optimizes the execution time of macOS builds and adds initial
(no-op) support for Windows.  Documentation now admits the issues with
macOS wheels.

Because of GH-63, CI/CD for Python 3.8 on macOS is temporarily dropped.

Build reference for upcoming v0.1.3
McSinyx added a commit that referenced this issue Apr 21, 2020
@McSinyx
Update CI/CD
e674ade 
This optimizes the execution time of macOS builds and adds initial
(no-op) support for Windows.  Documentation now admits the issues with
macOS wheels.

Because of GH-63, CI/CD for Python 3.8 on macOS is temporarily dropped.

Build reference for upcoming v0.1.3
@McSinyx McSinyx mentioned this issue May 1, 2020
Merged
@McSinyx
Copy link
Owner Author

McSinyx commented May 1, 2020

Seems to be a delocate's bug, as showed in matthew-brett/delocate#63, coincidentally.

@McSinyx McSinyx added the blocked Not our fault that this cannot be done (yet) label May 1, 2020
@McSinyx McSinyx changed the title Wheels for macOS do not include dynamically-linked libraries Bundled dylibs are not linked properly on macOS May 5, 2020
@McSinyx
Copy link
Owner Author

McSinyx commented May 5, 2020 •
edited

Per an offline discussion with Dr @trahoa, GH-92 only solve half of the problem. When palace 0.2.0 installed from the wheel on PyPI is imported, libalure2.dylib couldn't be found and Python looked for @rpath/libalure2.dylib instead of {site}/palace.dylibs/libalure2.dylib.

I'll try to work with delocate's devs to see if we can figure something out.

Edit: Just took a more careful look at Travis' log and the issue is only with Python 3.7 and 3.8; the wheel seems fine with 3.6.

@McSinyx McSinyx reopened this May 5, 2020
@McSinyx McSinyx pinned this issue May 5, 2020
@McSinyx McSinyx mentioned this issue May 5, 2020
Closed
McSinyx added a commit that referenced this issue May 16, 2020
@McSinyx
Opt out CI/CD for Python 3.7 and 3.8 on macOS
c24df31 
As per GH-63, wheels built on these platforms
are not properly repaired.
@McSinyx
Copy link
Owner Author

McSinyx commented Nov 12, 2020

Discussion moved to the mailing list.

@McSinyx McSinyx closed this as completed Nov 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
blocked Not our fault that this cannot be done (yet) distribution Packaging and distributing of source and binary help wanted Extra attention is needed
Projects
None yet
Milestone
1.0
Development

Successfully merging a pull request may close this issue.

Repair wheels on macOS correctly McSinyx/palace
1 participant
@McSinyx