Ticket #31303 (closed defect: duplicate)
libglade2 binary package links against libgtk-x11 even with gtk2 +quartz
| Reported by: | kliuless@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.0.3 |
| Keywords: | Cc: | dports@…, greisberger@…, ak.ml@… | |
| Port: | libglade2 |
Description
I have "+no_x11 +quartz" in my /opt/local/etc/macports/variants.conf file.
port install py27-gtk fails because it's looking for libgtk-x11-2.0.la . I tried the symlink workaround in ticket #22331 but now it complains about a missing libXinerama.la.
Using "grep libXinerama.la -r /opt/local/lib" I see /opt/local/lib/libglade-2.0.la which belongs to libglade2.
macports 2.0.3 installs libglade2 as a pre-built binary linked to x11 libs, as evidenced by "otool -L /opt/local/lib/libglade-2.0.0.0.7.dylib".
Is there a workaround for this? Is it possible to force a local build of libglade2, and would that even help? (I'm ultimately trying to install kate which depends on py27-gtk.)
Change History
comment:1 Changed 21 months ago by macsforever2000@…
- Keywords py27-gtk, libglade2, pre-built removed
comment:2 Changed 21 months ago by dports@…
- Cc dports@… added
- Port changed from py27-gtk to libglade2
- Summary changed from Can't build py27-gtk with "+no_x11 +quartz" due to pre-built libglade2 to libglade2 binary package links against libgtk-x11 even with gtk2 +quartz
I was about to file a ticket about this myself. I've noticed this issue with libglade2 and libgnomecanvas. Probably there are other ports too, but I haven't run into them yet.
As a workaround, you can force a build from source with port -s install libglade2
One way to solve this might be to have a dummy +quartz variant that just serves to distinguish the binary packages. (Really, it should depend on the +quartz variant of gtk2, but we can't do variant dependencies.)
comment:4 Changed 20 months ago by dports@…
I added a dummy +quartz variant to libgnomecanvas and libglade2 in r85431, which should solve the problem for now.
It's not a great fix, so I'll leave this bug open.
Other gtk2 dependents will probably have the same problem, so we should think about doing something like separate subports for the quartz versions of these ports, perhaps through a gtk portgroup. See also http://lists.macosforge.org/pipermail/macports-dev/2011-September/016287.html
comment:5 Changed 20 months ago by jmr@…
Yeah, variants have always been an insufficient tool for making a change that causes dependents to build differently as well, binaries just make it clearer. Ports with no dependents (or only dependents that don't change in response to the dependency's +quartz variant) can still use a variant, but that variant will have to change the deps from e.g. gtk2-x11 to gtk2-quartz (and those would have to be subports).