pangox-compat @0.0.2: error: implicit declaration of function 'pango_config_key_get' is invalid in C99

[evan814378]

After trying to figure out several things to install gwyddion in Mac OS Monterey, errors still show as follows

---> Building pangox-compat
Error: Failed to build pangox-compat: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_pangox-compat/pangox-compat/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port gwyddion failed

Anybody encountered this issue also?

[ryandesign (Ryan Carsten Schmidt)]

Attach the main.log file so that we can see what happened.

[ryandesign (Ryan Carsten Schmidt)]

I see we have ​build failures on our Monterey build machine too:

pangox-fontmap.c:944:21: error: implicit declaration of function 'pango_config_key_get' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
  char *files_str = pango_config_key_get ("PangoX/AliasFiles");
                    ^

pangox.c:282:15: error: no member named 'find_shaper' in 'struct _PangoFontClass'
  font_class->find_shaper = pango_x_font_find_shaper;
  ~~~~~~~~~~  ^

/opt/local/include/glib-2.0/glib/gmacros.h:990:38:: error: implicit declaration of function 'pango_font_metrics_new' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
      metrics = pango_font_metrics_new ();
                ^
note: expanded from macro 'GLIB_DEPRECATED_MACRO_FOR'
#define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning #f)
                                     ^

[ryandesign (Ryan Carsten Schmidt)]

We had successful builds of pangox-compat in December 2020 but since that time pango has been updated from 1.42.x to 1.48.x; I suspect that it no longer provides the functions that pangox-compat needs. For example in comment:ticket:63585:20 Evan said:

pango_font_metrics_new was moved from a public header to a private header in Pango, I guess between 1.42 and 1.48

[ryandesign (Ryan Carsten Schmidt)]

I've reported the issue to the developers of pango: ​https://gitlab.gnome.org/GNOME/pango/-/issues/644

[arohl (Andrew Rohl)]

Is there any way to force macports to use the older version of pango so that I can still compile pangox-compat (which I need for gtkglext).

Many thanks

Andrew

[ryandesign (Ryan Carsten Schmidt)]

Not recommended, may cause other issues, but the way to do that is described at wiki:howto/InstallingOlderPort.

The ultimate solution may involve fixing all of the ports that use pangox-compat (that's only gtkglext and libbonoboui) so that they no longer require it, and then removing pangox-compat, since the developers don't seem interested in it anymore.

[someuser12]

For libbonoboui, it seems one can replace pangox-compat with pango without harm, at least on the latest versions of MacOS (see ​https://github.com/macports/macports-ports/pull/13652).

[someuser12]

In 12cfe0e04b930dca5f9efa51828bc195412c8550/macports-ports (master):

libbonoboui: replace dep to pangox-compat with pango
See: #64228
Co-authored-by: Renee Otten <renee.otten@…>

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #64627.

[ramadugu]

any update on changing pangox-compat to pango for gtkglext similar to how it was done to libbonoboul? Thanks for all the work and time that you put into these ports!

[ramadugu]

@ryandesign, sorry for bothering, is there a way to install the gtkglext without pangox like the libbonoboui? My attempts at having a local port didn't work we have a research project stalled and I am not experienced to resolve this, hence reaching out again. Thanks, Sai

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #65171.

Replying to 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 ​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 ​reported the same to redhat; the issue was closed due to inactivity.

Development of 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 ​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 ​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.

[ramadugu]

thank you for a detailed explanation. Makes things much clear now than before.

[barracuda156]

On 10.6.8 Rosetta I get this error:

pangox.c: In function 'pango_x_font_class_init':
pangox.c:282: error: 'PangoFontClass' has no member named 'find_shaper'

[jdolan (Jay Dolan)]

Oof. I just hit this attempting to install gtkglext for GtkRadiant (Quake level editing software). Is there any recommended workaround? This was all working fine on my Catalina machine. I'm running Monterey now.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #65919.

I have no workaround for you. I explained above what the problem is and what the possible solutions are.

[jdolan (Jay Dolan)]

Thanks. I was able to install gtkglext through Homebrew, so.. that's at least a viable option for now.

[ryandesign (Ryan Carsten Schmidt)]

In 2184bf85084650d8b1219895f3b554a65e4420ad/macports-ports (master):

pangox-compat: Fix build with current pango

Closes: #64228

[ryandesign (Ryan Carsten Schmidt)]

Be warned that although pangox-compat compiles now I don't know if it works. For example, ghemical crashes on launch in a pangox-function.