-
Notifications
You must be signed in to change notification settings - Fork 91
Dynamic cairo symbol lookup #421
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
base: main
Are you sure you want to change the base?
Conversation
99eec9d to
2b01240
Compare
2b01240 to
a96be45
Compare
|
The main thing is that statically linking on non-Windows will fail with this, and I wonder if there is a way to detect that automatically. |
|
I wonder if this could solve a few issues: One I use case I think is really interesting, is having parallel builds of cairo with different --enable flags (built at the same time). Another is cairo built in a virtualenv vs in the system. |
|
Yeah, the combination of distros changing something with cairo + cached wheels from previous pycairo installs is one source of conflicts. |
I doesn't seem there is. So we might have to add an option to disable this in case someone wants to link statically (rare on non-Windows). On Windows we can use |
|
For example, vim has: You could make it an error to static link while also setting it to dlopen? The distinguishing factor is basically "did the user set -static in LDFLAGS", right? You could check this via a cc.run() check perhaps. |
This avoids using any of the xlib and xcb APIs provided by cairo as if cairo was not built with support for those. This is to allow downstream to provide non-x cairo builds, and a pycairo build that works with both cairo variants. PR pygobject#421 is a more dynamic solution for this problem, but this is easier and less risky for now. See pygobject#420
This avoids using any of the xlib and xcb APIs provided by cairo as if cairo was not built with support for those. This is to allow downstream to provide non-x cairo builds, and a pycairo build that works with both cairo variants. PR pygobject#421 is a more dynamic solution for this problem, but this is easier and less risky for now. See pygobject#420
This avoids using any of the xlib and xcb APIs provided by cairo as if cairo was not built with support for those. This is to allow downstream to provide non-x cairo builds, and a pycairo build that works with both cairo variants. PR #421 is a more dynamic solution for this problem, but this is easier and less risky for now. See #420
wip
A test to see if we could load cairo symbols at runtime only when needed, so a pycairo doesn't need to be rebuilt if cairo is rebuilt with a different config.
I've never done something like this, so not sure how portable that all is. With some macro magic we could make it optional if that turns out to be tricky.