py-cairo should support a +x11 variant

[jenstroeger (Jens Troeger)]

Might be related to #34889 or #34724.

My cairo @1.14.2_1+quartz is built without x11 support, and I added py34-cairo @1.10.0_3 just now. However, when I then try to load cairo from Python, loading the library fails with what I suspect is a missing x11 symbol:

>>> import cairo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/cairo/__init__.py", line 18, in <module>
    from ._cairo import *
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/cairo/_cairo.so, 2): Symbol not found: _cairo_xlib_surface_get_depth
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/cairo/_cairo.so
  Expected in: /opt/local/lib/libcairo.2.dylib
 in /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/cairo/_cairo.so

[ryandesign (Ryan Carsten Schmidt)]

Did you get a binary from our packages server, or build py34-cairo from source? I suspect you got a binary. I suspect py-cairo builds itself differently depending on whether cairo has x11 support or not. Therefore, py-cairo should have an x11 variant, and use the require_active_variants procedure in the active_variants 1.1 portgroup to ensure a match between the variants of the py-cairo subports and the cairo port. That is what was done in r100265 to fix #34889. It was undone in r129111; see #38606. The removal of this code appears to have been incorrect and it or something like it should be reinstated.

[ryandesign (Ryan Carsten Schmidt)]

The code that was removed in r129111 doesn't look like it was completely correct. I'm not sure why the catch portion was there. And although it correctly ensures that if py*-cairo is built +x11 then cairo must be built +x11, it does not ensure that if py*-cairo is built -x11 then cairo must be built -x11.

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[jenstroeger (Jens Troeger)]

Replying to ryandesign@…:

Did you get a binary from our packages server, or build py34-cairo from source? I suspect you got a binary.

How do I tell the difference, now that it's installed? It's been a while since I've put cairo on this machine.

[ryandesign (Ryan Carsten Schmidt)]

If you don't remember, then I'm not sure of way to find out after the fact.

You could reinstall the port, enforcing the use of a binary, and see if it still fails to work (I suspect it will). To do this, run:

sudo port -bn upgrade --force py34-cairo

Then you could rebuild the port locally on your machine, and see if this now works (I suspect it will). To do this, run:

sudo port -sn upgrade --force py34-cairo

[jenstroeger (Jens Troeger)]

Hum. The first command failed to install py34-cython (fetch failed) so I removed py34-cairo altogether. Trying to build from source started to pull down the whole of gcc49 at which point I interrupted (don't want too much cruft in my tree).

I prefer to wait for a fix to the binary packets :)

[ryandesign (Ryan Carsten Schmidt)]

Ah yes, because py34-cairo has a build dependency on py34-cython, which has a build dependency on gcc49. That is a clue for us that you did indeed receive a binary before, because build dependencies are not needed to install binaries.

[jenstroeger (Jens Troeger)]

Can you guesstimate how long a fix will take? It sounds like you know how to resolve this already...

[ryandesign (Ryan Carsten Schmidt)]

I'd like to wait until the port's maintainer, Sean, has had a chance to look at the situation.

If we fix it the way I suggest, you'll still have to build py34-cairo from source, because we only have packages for default variants, and we use the +x11 variant by default, and you are wanting to not use x11.

Sean, why does building py*-cairo require py*-cython which requires a gcc compiler? That is not optimal. Can it be avoided?

[seanfarley (Sean Farley)]

Jeremy was the last one to touch this logic and I haven't had time to look into it deeply yet. If you feel you have a good solution, Ryan, I trust you. Else, I can try to look at it sometime this week.

[jeremyhu (Jeremy Huddleston Sequoia)]

Damn, that's unfortunate...

Well, if we need to revert r129111, that's certainly fine, but we should try and find a better long term solution.

[ryandesign (Ryan Carsten Schmidt)]

Replying to sean@…:

Jeremy was the last one to touch this logic and I haven't had time to look into it deeply yet. If you feel you have a good solution, Ryan, I trust you. Else, I can try to look at it sometime this week.

I feel that we basically had the solution before Jeremy removed it.

Replying to jeremyhu@…:

Well, if we need to revert r129111, that's certainly fine, but we should try and find a better long term solution.

Do you mean the developers of py-cairo should find a better solution, such that py-cairo's build does not differ depending on whether Cairo uses X11 and/or Quartz, or do you mean that we should find a better solution in MacPorts for handling ports whose build differs based on the build of a dependency?

[jeremyhu (Jeremy Huddleston Sequoia)]

No, I mean that installing the cairo port should always install the Quartz rendering backend and optionally install the X11 rendering backend.

py-cairo should similarly always support the Quartz backend and optionally support the X11 backend if cairo supports it.

My understanding from talking to others was that py-cairo was agnostic to the rendering backend, but it seems that isn't the case.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

No, I mean that installing the cairo port should always install the Quartz rendering backend and optionally install the X11 rendering backend.

That is already the case since r128925; see #44414.

py-cairo should similarly always support the Quartz backend and optionally support the X11 backend if cairo supports it.

My understanding from talking to others was that py-cairo was agnostic to the rendering backend, but it seems that isn't the case.

py-cairo already does optionally support x11 if cairo supports it, but the check for whether cairo supports x11 appears to be happening at build time, whereas it seems like it would be better for it to happen at runtime.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, digested this a bit more.

The issue in #38606 was that cairo needed to be installed +x11-quartz for py-cairo to work (or so was reported by the Portfile).

py-cairo should be able to support both X11 and Quartz backends at the same time. I believe this was the case when I submitted r129111, and I believe that is still the case today.

Reverting r129111 won't fix the issue.

It looks to me like the issue here is that:

1. User installed cairo +x11
2. User installed py-cairo (which supported +x11
3. User upgraded cairo as -x11

The installed py-cairo then no longer worked.

It would be best if py-cairo had an x11 variant such that when it was enabled, we ensured that cairo's +x11 variant is enabled. Similarly, if it is disabled, we need to ensure that py-cairo is built without the X11 support (but we obviously don't care if cairo is).

[jeremyhu (Jeremy Huddleston Sequoia)]

Retitling to match above.

Also, I suspect the workaround here is for the user to just rebuild py34-cairo.

[jenstroeger (Jens Troeger)]

Why does it matter to the Python bindings whether Cairo is built with +x11 or +Quartz?

[jenstroeger (Jens Troeger)]

Replying to jeremyhu@…:

Also, I suspect the workaround here is for the user to just rebuild py34-cairo.

Rebuilding from source would pull in all sorts of other packages (like gcc4.9) which I'd like to avoid.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

It looks to me like the issue here is that:

1. User installed cairo +x11
2. User installed py-cairo (which supported +x11
3. User upgraded cairo as -x11

The installed py-cairo then no longer worked.

I would instead assume the sequence of events was:

1. User installed cairo +quartz
2. User installed py34-cairo

Because the user did not specify any nonstandard variants for py34-cairo, he received a binary from our server, but on our server, cairo would have been built with X11, so he got a version of py34-cairo that required X11, though it did not have an x11 variant indicating that.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jens.troeger@…:

Replying to jeremyhu@…:

Also, I suspect the workaround here is for the user to just rebuild py34-cairo.

Rebuilding from source would pull in all sorts of other packages (like gcc4.9) which I'd like to avoid.

Unless the developers of py-cairo change their software to be agnostic of cairo's capabilities, this will be unavoidable.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

I would instead assume the sequence of events was:

1. User installed cairo +quartz
2. User installed py34-cairo

Because the user did not specify any nonstandard variants for py34-cairo, he received a binary from our server, but on our server, cairo would have been built with X11, so he got a version of py34-cairo that required X11, though it did not have an x11 variant indicating that.

I should correct that:

1. User installed cairo -x11

+quartz is always on, and +x11 is on by default, but can be disabled.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jens.troeger@…:

Why does it matter to the Python bindings whether Cairo is built with +x11 or +Quartz?

I don't know the inner workings of the package. I just see that it does because it's using the cairo_xlib_surface_get_depth function from libcairo, so presumably, it's making a python binding for that function. If they wanted, they could just make the optional symbols weak and check for availability at runtime, but that is beyond the scope of MacPorts.

I think we just need to add an x11 variant and hopefully there is functionality in py-cairo to disable support for the X11 backend even if it's available in the base cairo.

[su-v]

Replying to jens.troeger@…:

Rebuilding from source would pull in all sorts of other packages (like gcc4.9) which I'd like to avoid.

Maybe you could consider rebuilding from source with variant -gfortan (AFAICT this prevents that py-numpy pulls in a gcc dependency).

[seanfarley (Sean Farley)]

So, what's the status with this ticket?

[wdc@…]

I just did a clean

sudo port install meld

on a yosemite system. My variants.conf file is: -x11 +no_x11 +quartz

But I get the error:

Symbol not found: _cairo_xlib_surface_get_depth

which says to me that Quartz py27-cairo now has an X11 dependency that cannot be satisfied.

So I think this is still a problem. My py27-cairo is 1.10.0_3.

[wdc@…]

I spent some quality time on the #macports IRC channel today. geekosaur and Ionic helped me resolve the problem. Root cause:

Transition from an X11 setup to a Quartz setup.

Even though I did

sudo port uninstall installed vi variants.conf sudo port install meld

the py27-cairo that was installed was built with X11 and so it didn't rebuild.

I was cautioned not to execute the following willy-nilly without knowing what it's doing and its possible dependencies. Nevertheless the following command resolved my problem:

sudo port -nsvt upgrade --force py27-cairo

[wdc@…]

One further idea discussed on the IRC channel:

py27-cairo, if it had explicit quartz and x11 variants would, perhaps notice a variants.conf change and rebuild. It DOES have different behaviors when built in the two different contexts, so separate variants really do seem necessary here. Is there something I can do to help make this happen?

[petrrr]

Cc Me!

[seanfarley (Sean Farley)]

Ok, I still don't know what's going on with this ticket. I'm marking it closed but if it's still an issue please assign to Ryan or Jeremy since they seem to have a better grasp.