[MacPorts] #64228: pangox-compat @0.0.2: error: implicit declaration of function 'pango_config_key_get' is invalid in C99

[MacPorts]

#64228: pangox-compat @0.0.2: error: implicit declaration of function
'pango_config_key_get' is invalid in C99
----------------------------+------------------------
  Reporter:  evan814378     |      Owner:  ryandesign
      Type:  defect         |     Status:  accepted
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:
Resolution:                 |   Keywords:
      Port:  pangox-compat  |
----------------------------+------------------------
Changes (by ryandesign):

 * cc: Steph152309 (added)


Comment:

 Has duplicate #65171.

 Replying to [comment:11 ramadugu]:
 > is there a way to install the gtkglext without pangox like the
 libbonoboui?

 The situation is not the same.

 In 2012, the developers of pango decided to remove the pangox
 functionality from pango. It was moved to a separate project called
 pangox-compat (which has now bitrotted and doesn't build when using a
 recent enough version of pango, which is the situation we now find
 ourselves in in MacPorts).

 The most recent version of gtkglext was released in 2006 while the most
 recent version of libbonoboui was released in 2011. So the situation is
 similar in that both of those projects were written at a time when having
 pango meant automatically also having pangox.

 The difference is that libbonoboui doesn't actually use pangox. It
 references the pangox pkg-config file in its configure script, as well as
 the pangoxft pkg-config file if it exists. pangoxft is still a part of
 pango today so its pkg-config file does exist (at least when pango is
 compiled with the +x11 variant, and the libbonoboui port basically
 requires that to be the case). libbonoboui's configure script uses the
 combined output from both of the pango pkg-config files to determine
 whether pango was linked with X11. If it was, libbonoboui doesn't link
 itself with X11. (This will be the case if pangox-compat is installed.) If
 it wasn't, libbonoboui does. (This will be the case if pangox-compat is
 not installed.)

 gtkglext on the other hand does use pangox, which can be easily
 demonstrated: If the pangox-compat dependency is simply removed from the
 gtkglext port as was done with libbonoboui, gtkglext will then fail at the
 configure step when it can't find pangox:

 {{{
 checking for BASE_DEPENDENCIES... configure: error: Package requirements
 (gtk+-2.0 >= 2.0.0 gdk-2.0 >= 2.0.0 pango >= 1.0.0 pangox >= 1.0.0
 gmodule-2.0 >= 2.0.0 ) were not met:
 No package 'pangox' found
 }}}

 If the configure check for the existence of pangox is deleted, then the
 build fails when it tries to include the nonexistent pangox header:

 {{{
 gdkglfont-x11.c:21:10: fatal error: 'pango/pangox.h' file not found
 #include <pango/pangox.h>
          ^~~~~~~~~~~~~~~~
 1 error generated.
 }}}

 If the inclusion of the pangox header is replaced with an inclusion of the
 pango header, then the build fails when it tries to use the nonexistent
 pangox features:

 {{{
 gdkglfont-x11.c:80:3: error: use of undeclared identifier 'PangoXSubfont'
   PangoXSubfont subfont_id;
   ^
 }}}

 So the only solutions are to rewrite pangox-compat so that it regains
 compatibility with the latest pango (which the developers of pangox-compat
 have shown no interest in doing) or to rewrite gtkglext so that it does
 not use pangox.

 The developer of pango reported to the developers of gtkglext in 2009 that
 they are [https://sourceforge.net/p/gtkglext/bugs/23/ linking with pangox
 without using it], and he requested that they stop doing that, but there
 was no reply to that ticket, and I'm not sure what to make of it given
 what I showed above which seems to show that gtkglext really does use
 pangox. He also [https://bugzilla.redhat.com/show_bug.cgi?id=516588
 reported the same to redhat]; the issue was closed due to inactivity.

 Development of gtkglext [https://gitlab.gnome.org/Archive/gtkglext
 continued on gnome's gitlab], including commits that removed the pangox
 requirement, however they never released a new stable version including
 those changes and the project is now archived so there won't be any
 further releases.

 Some other distributions like
 [https://bugzilla.redhat.com/show_bug.cgi?id=850813#c7 redhat were asked
 to update to that newer unreleased version of gtkglext], however it was
 pointed out that it is incompatible with the last released version of
 gtkglext in that it simply removes the gtkglext functionality that relied
 upon pangox, which could be a problem for other programs that relied on
 that gtkglext functionality. Redhat decided to instead rely on pangox-
 compat, but that was back in 2013 when pangox-compat could still be used.
 I'm not certain what they've done about it since then.

 Some other distributions like [https://bugs.gentoo.org/698950 gentoo were
 asked to remove gtkglext] since it is thought that its functionality has
 been superseded by gtk, however there is disagreement on that point in the
 bug report.

 We could investigate each port that uses gtkglext and see if there is a
 newer version or another way to make it not use gtkglext anymore.

 If that's not possible, we could try to update gtkglext to the unreleased
 version and see if all of the ports that declare dependencies on gtkglext
 still build and work after that.

 Or we could try to fix the pangox-compat build problem. As I understand
 it, pangox-compat, having been a part of pango, uses internal pango APIs
 which have changed.

-- 
Ticket URL: <https://trac.macports.org/ticket/64228#comment:12>
MacPorts <https://www.macports.org/>
Ports system for macOS