Opened 3 years ago
Closed 3 years ago
#63585 closed defect (fixed)
py27-pygtk: error: implicit declaration of function 'pango_font_metrics_new' is invalid in C99
Reported by: | rhstanton | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | catalina bigsur | Cc: | beechbrandt, i0ntempest, dershow, cooljeanius (Eric Gallager), evanmiller (Evan Miller) |
Port: | py-pygtk |
Description
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 ^
Change History (24)
comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | catalina bigsur added |
---|---|
Port: | py-pygtk added; py27-pygtk removed |
Summary: | Error building py27-pygtk → py27-pygtk: error: implicit declaration of function 'pango_font_metrics_new' is invalid in C99 |
comment:2 Changed 3 years ago by beechbrandt
Cc: | beechbrandt added |
---|
comment:3 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | i0ntempest added |
---|---|
Owner: | set to mascguy |
Status: | new → assigned |
comment:4 Changed 3 years ago by mascguy (Christopher Nielsen)
comment:5 Changed 3 years ago by dershow
Cc: | dershow added |
---|
comment:6 Changed 3 years ago by 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.
comment:7 follow-ups: 9 15 19 Changed 3 years ago by 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!
comment:8 Changed 3 years ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:9 follow-up: 11 Changed 3 years ago by mascguy (Christopher Nielsen)
Replying to evanmiller:
@mascguy Might have some other side effects, but try removing
#define PANGO_ENABLE_BACKEND
frompango.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.
Currently evaluating other options...
comment:10 Changed 3 years ago by Christopher Nielsen <mascguy@…>
comment:11 follow-up: 12 Changed 3 years ago by 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).
comment:12 Changed 3 years ago by 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.
comment:13 Changed 3 years ago by jmroot (Joshua Root)
Also allowing it to build on arm64 when it's potentially broken there isn't good though.
comment:14 Changed 3 years ago by 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
comment:15 Changed 3 years ago by mascguy (Christopher Nielsen)
Replying to evanmiller:
@mascguy Might have some other side effects, but try removing
#define PANGO_ENABLE_BACKEND
frompango.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.
comment:16 Changed 3 years ago by 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.
comment:17 Changed 3 years ago by Christopher Nielsen <mascguy@…>
comment:18 Changed 3 years ago by evanmiller (Evan Miller)
Cc: | evanmiller added |
---|
comment:19 Changed 3 years ago by mascguy (Christopher Nielsen)
Replying to evanmiller:
@mascguy Might have some other side effects, but try removing
#define PANGO_ENABLE_BACKEND
frompango.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.
comment:20 Changed 3 years ago by 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
comment:21 Changed 3 years ago by 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?
comment:22 Changed 3 years ago by 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:
comment:23 Changed 3 years ago by Christopher Nielsen <mascguy@…>
comment:24 Changed 3 years ago by Christopher Nielsen <mascguy@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Currently looking at this. Hopefully we'll have a resolution within the next day or two.