py27-pygtk: error: implicit declaration of function 'pango_font_metrics_new' is invalid in C99

[rhstanton]

Running port upgrade outdated, I get the following error:

Error: Failed to build py27-pygtk: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pygtk/py27-pygtk/main.log for details.

Looking in the log file, I see several errors relating to implicit function definitions:

:info:build pango.c:3986:16: error: implicit declaration of function 'pango_font_metrics_new' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
:info:build         return pango_font_metrics_new();
:info:build                ^

[mascguy (Christopher Nielsen)]

Currently looking at this. Hopefully we'll have a resolution within the next day or two.

[mascguy (Christopher Nielsen)]

For anyone interested, I've been actively working on this today.

Thus far, I haven't found a quick fix. But still digging through plenty of technical minutia.

[evanmiller (Evan Miller)]

@mascguy Might have some other side effects, but try removing #define PANGO_ENABLE_BACKEND from pango.override. Would try myself but my local vim is broken and it's time to retire for the evening!

[mascguy (Christopher Nielsen)]

Replying to evanmiller:

@mascguy Might have some other side effects, but try removing #define PANGO_ENABLE_BACKEND from pango.override. Would try myself but my local vim is broken and it's time to retire for the evening!

Great idea Evan, I'll give that a try.

In terms of where I'm currently at: Based on the compilation errors related to C99, my first thought was to patch the build to specify C11. But that alone didn't make a difference, which suggests that there's more to it.

Simply specify the C11 standard to configure didn't cut it either, perhaps due to the AutoConf script. But this patch - as ugly as it is - does take care of that. But again, it didn't make a difference, so I could use some guidance from any of you folks with more familiarity with Clang intricacies:

​https://github.com/macports/macports-ports/compare/master...mascguy:mascguy-pygtk

[Christopher Nielsen <mascguy@…>]

In b28d2e9c79941c007dfd3d6ef07bab91cc120ea9/macports-ports (master):

py-pygtk: fix for implicit function declaration errors

See: #63585

[jmroot (Joshua Root)]

Replying to mascguy:

In terms of where I'm currently at: Based on the compilation errors related to C99, my first thought was to patch the build to specify C11. But that alone didn't make a difference, which suggests that there's more to it.

Implicit declaration is only allowed in C89 and K&R C. The correct fix is to provide function prototypes before calling the functions, usually by including an appropriate header. -Wno-error=implicit-function-declaration is no longer the default because implicit declaration is unsafe on arm64 (different ABI depending on what type of arguments a function takes).

[mascguy (Christopher Nielsen)]

Replying to jmroot:

Implicit declaration is only allowed in C89 and K&R C. The correct fix is to provide function prototypes before calling the functions, usually by including an appropriate header. -Wno-error=implicit-function-declaration is no longer the default because implicit declaration is unsafe on arm64 (different ABI depending on what type of arguments a function takes).

Yep for sure; I purposely left this ticket open, as the initial fix is intended to stop the bleeding on x86.

I'm now looking at potential code patches, to see if it's a simple matter of correcting header inclusion.

[jmroot (Joshua Root)]

Also allowing it to build on arm64 when it's potentially broken there isn't good though.

[mascguy (Christopher Nielsen)]

Update: New port py-pygtk-devel created for testing a more definitive fix, including Evan's suggestion mentioned in comment:7:

​https://github.com/macports/macports-ports/commit/9b9744efd93aea1573983921d004454d494a42b8

[mascguy (Christopher Nielsen)]

Replying to evanmiller:

@mascguy Might have some other side effects, but try removing #define PANGO_ENABLE_BACKEND from pango.override. Would try myself but my local vim is broken and it's time to retire for the evening!

This doesn't appear to make a difference, though perhaps there's more to it.

Was hoping to avoid getting too far into the weeds, but perhaps it's time for a deep-dive into the intricacies of this port.

That said, follow-up thoughts welcome in the interim.

[mascguy (Christopher Nielsen)]

Reflecting on what the the goal of PyGtk is - generation of Python bindings, for GTK, Pango, etc - it just occurred to me: Given that PyGtk hasn't been updated since 2011, the newer Pango functions may simply need formal mappings.

If so, correcting that would ensure generation of the function prototypes... at least in theory.

Still digging, but things are making more sense now.

[Christopher Nielsen <mascguy@…>]

In 66d79c300d6a718fff5165c157c2c775ba17c565/macports-ports (master):

py-pygtk-devel: patch to disable pango backend

See: #63585

[mascguy (Christopher Nielsen)]

Replying to evanmiller:

@mascguy Might have some other side effects, but try removing #define PANGO_ENABLE_BACKEND from pango.override. Would try myself but my local vim is broken and it's time to retire for the evening!

Evan, I made this change in the Devel port, even though it's not effective. (Also tried patching pango.defs, completely removing everything that's enabled via PANGO_ENABLE_BACKEND. But again, didn't make a difference. The latter change wasn't pushed though, as it seems pointless.)

Nonetheless, if you're interested in seeing the result, go ahead and install the Devel version.

Thoughts/suggestions welcome.

[evanmiller (Evan Miller)]

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

Couple things to try:

Add this line to pango.override, after #include <pango.h>

PANGO_AVAILABLE_IN_ALL PangoFontMetrics *pango_font_metrics_new (void);

On line 525 of the same file, try adding *_new to the ignore-glob list

[evanmiller (Evan Miller)]

@jmroot> implicit declaration is unsafe on arm64 (different ABI depending on what type of arguments a function takes).

The function in question takes no arguments and returns a pointer – are we safe on arm64 then?

[mascguy (Christopher Nielsen)]

Thanks to work by upstream's Lukas Oberhuber (@lukasco via gitlab.gnome.org), a formal patch is now available for this issue. And I'll be testing ASAP.

Discussion thread:

​https://gitlab.gnome.org/GNOME/gimp/-/issues/5952#note_1301318

Patch:

​https://gitlab.gnome.org/samm-git/gtk-osx/-/blob/50d3c72e53974dc27ed97d061cbaaa89be8bf1bf/patches/pygtk-fails-to-build.patch

[Christopher Nielsen <mascguy@…>]

In 5d2d0c22d736959c888624f9cdf36ae94efa450d/macports-ports (master):

py-pygtk: fix implicit function declarations

• Patch provided by upstream's Lukas Oberhuber
• Also re-enable warnings related to implicit function declarations
• Add missing declaration for dist_subdir

See: #63585

[Christopher Nielsen <mascguy@…>]

In 1828c7afa1b4a6e50b7072ac7adda483a4029652/macports-ports (master):

py-pygtk: reconcile with py-pygtk-devel

• Includes fix for implicit function declarations, etc

Fixes: #63585