Opened 3 months ago

Closed 6 weeks ago

Last modified 6 weeks ago

#61508 closed defect (fixed)

gobject-introspection generates invalid gir files on Big Sur

Reported by: idryzhov (Igor Ryzhov) Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: Cc: libsystem-ethan, michaelld (Michael Dickens), drkp (Dan Ports), ra1nb0w, thenickdude (Nicholas Sherlock), rseichter (Ralph Seichter), hapaguy (Brian Kurt Fujikawa)
Port: gobject-introspection

Description (last modified by ryandesign (Ryan Schmidt))

Examples of ports with invalid gir files:

gdk-pixbuf2:

$ grep libgdk /opt/local/share/gir-1.0/* -r
/opt/local/share/gir-1.0/GdkPixbuf-2.0.gir:             shared-library="libgdk_pixbuf-2.0.0.dylib"
/opt/local/share/gir-1.0/GdkPixdata-2.0.gir:             shared-library="libgdk_pixbuf-2.0.0.dylib"

atk:

$ grep libatk /opt/local/share/gir-1.0/* -r
/opt/local/share/gir-1.0/Atk-1.0.gir:             shared-library="libatk-1.0.0.dylib"

Paths should be absolute, but they are not. This problem leads to errors like in ticket #61471

Change History (26)

comment:1 Changed 3 months ago by ryandesign (Ryan Schmidt)

Description: modified (diff)
Owner: set to dbevans
Status: newassigned

comment:2 Changed 3 months ago by libsystem-ethan

Cc: libsystem-ethan added

comment:3 Changed 3 months ago by ryandesign (Ryan Schmidt)

#61571 might be the same problem.

comment:4 Changed 3 months ago by kencu (Ken)

we should stop updating or revbumping anything that uses gobject-introspection until this gets sorted out.

Ah -- poppler -- what have you done to us...all this stems from you...

comment:5 Changed 3 months ago by kencu (Ken)

Cc: michaelld added

comment:6 Changed 3 months ago by kencu (Ken)

Michael, copying you in --

There is a (not really right) PR trying to fix this... see <https://github.com/macports/macports-ports/pull/9154> and also <https://github.com/macports/macports-ports/pull/9071>

comment:7 Changed 3 months ago by michaelld (Michael Dickens)

Well ... arg ... Reviewing the GIR files installed right now on my system, I see that 95% of them show the correct shared-library ... but there are a few that are stubborn: even with the latest GO-I changes they still produce just the library name, not the full path. Luckily, it was this way before too ... they just an issue in creating the GIR file!

I'm going to try out @idryzhov's PR to see if it fixes this issue for those stubborn ports. If so, then that's a key on how to fix them ... that PR, once fixed as I've requested, might be the way to go along with mine.

comment:8 Changed 3 months ago by michaelld (Michael Dickens)

FYI the stubborn ports I note all use "@rpath" for the in-build library, which is why this issue exists in the first place. The @rpath is replaced by the full path during install. GO-I would produce the same GIR file for these ports regardless of our current fixes.

@idryzhov's PR fixes this issue, but it is -very- dangerous to assume that the general install library is ${mp_prefix}/lib. The note in the code at this point reads [SIC]:

                # no way to resolve @rpath and the like, since we can't
                # make a reasonable assumpion of the install libdir

The "correct" fix is to not use @rpath in the first place when using GO-I scanner. About 95% of the ports that produce GIR files that I have installed don't use @rpath. The ones that do that I've reviewed this far all use meson for building ... is using @rpath a default setting somehow? I've looked through these project's source and see nothing obvious to indicate that @rpath is being used or not. I've never used meson before, so I have no idea what to do here to fix the issue. Note that such fixes are on a project-by-project basis, which is quite a PITA, even if it is the correct way to go here. Hmmm....

comment:9 Changed 3 months ago by kencu (Ken)

meson will always use @rpath during the build for any in-tree library references (for running tests, etc, to find the right library) and replaces it during install with the full path.

That's why we have the headache on Tiger and have to patch meson there.

It's a mechanism at the heart of meson, used on all non-windows os versions. They won't be changing it I believe.

Despite @rpath, this was all working until, I believe, /opt/local/lib began being removed from the library list so as to avoid adding it to DYLD_LIBRARY_PATH.

Last edited 3 months ago by kencu (Ken) (previous) (diff)

comment:10 in reply to:  9 Changed 3 months ago by michaelld (Michael Dickens)

Replying to kencu:

mesom will always use @rpath during the build for any in-tree library references (for running tests, etc, to find the right library) and replaces it during install with the full path.

That's why we have the headache on Tiger and have to patch meson there.

It's a mechanism at the heart of meson, used on all non-windows os versions. They won't be changing it I believe.

OK. Good to know. It's either lazy or pragmatic ... IDK which! One can always set DYLD_LIBRARY_PATH to test the in-build library; this is what CMake does by default rather than use @rpath. "To each" I guess ...

Despite @rpath, this was all working until, I believe, /opt/local/lib began being removed from the librsry list so as to avoid adding it to DYLD_LIBRARY_PATH.

Hmmm ... interesting conceptual observation ... I'm pretty sure the @rpath usage would result in a defective GIR file regardless of our/my GO-I tweaks thus far ... I'll test this to verify.

I'll also investigate if there's way to split the library paths so-as to provide a list to the shlibs.py scripts to less-dangerously work around this issue.

comment:11 Changed 3 months ago by kencu (Ken)

I'll remind you about this ticket you were involved in, which was not meson, but with a lot of gobject-introspection @rpath stuff going on that we worked on:

#60024

comment:12 Changed 3 months ago by michaelld (Michael Dickens)

Thanks for that reminder ... yup ... I wrote that section of code ... I honestly barely recall doing so even just 9 months down the road! Here's my comment, which is still relevant & makes me think creating a split set of library parameters will do the trick for this @rpath issue, with much more robustness than what we have right now or what is proposed:

My hack is to note that any library being linked via GI here will
require glib, which, at least in my testing, will always be the
first non-build library linkage supplied (the first linkages are to
the build directory, which is good because we always want those to
come first). So, the new code loops through the provided
library_paths (from the -L entries) and selects the first non-build
one & uses it for the "library install directory". Not perfect, but
in my testing it works very reliably for this specific case of how
GI and the g-ir-scanner are used. It won't in general work, of
course, but since the use case is very specific I'm willing to go with it.

comment:13 Changed 3 months ago by drkp (Dan Ports)

Cc: drkp added

comment:14 Changed 3 months ago by ra1nb0w

Cc: ra1nb0w added

comment:15 Changed 3 months ago by thenickdude (Nicholas Sherlock)

Cc: thenickdude added

comment:16 Changed 3 months ago by rseichter (Ralph Seichter)

Cc: rseichter added

comment:17 Changed 3 months ago by hapaguy (Brian Kurt Fujikawa)

Cc: hapaguy added

comment:18 Changed 3 months ago by Igor Ryzhov <iryzhov@…>

In c6a66222d49b790946347068dafbc8bcec546214/macports-ports (master):

gobject-introspection: fix generated gir files on Big Sur

Ref: #61508
Signed-off-by: Igor Ryzhov <iryzhov@…>

comment:19 Changed 3 months ago by michaelld (Michael Dickens)

The PR fix for this isn't ideal, but it works for most cases & is better than the lack of fix we have at the moment.

I'm closing this ticket as "fixed". If somebody comes up with exactly the same issue then please reopen and post a log. If the issue is similar but maybe not the same, then please open a new ticket.

comment:20 Changed 3 months ago by michaelld (Michael Dickens)

Resolution: fixed
Status: assignedclosed

comment:21 Changed 3 months ago by rseichter (Ralph Seichter)

Resolution: fixed
Status: closedreopened

I still have this problem. virt-manager is unable to load libatk:

$ virt-manager
** (virt-manager:68461): WARNING **: 02:32:25.841: Failed to load shared library 'libatk-1.0.0.dylib'
referenced by the typelib: dlopen(libatk-1.0.0.dylib, 9): image not found

The library exists as /opt/local/lib/libatk-1.0.0.dylib, but the gir file does not use that absolute path:

$ grep -r libatk /opt/local/share/gir-1.0/*
/opt/local/share/gir-1.0/Atk-1.0.gir:   shared-library="libatk-1.0.0.dylib"

comment:22 Changed 3 months ago by jmroot (Joshua Root)

Do the affected dependent ports need to be rev bumped?

comment:23 in reply to:  22 Changed 3 months ago by michaelld (Michael Dickens)

Replying to jmroot:

Do the affected dependent ports need to be rev bumped?

hmmm ... yes, doing a rev-bump should be done here to get the last PR's fixes for cases like the libatk GIR file.

comment:24 Changed 8 weeks ago by michaelld (Michael Dickens)

We've rev-bumped some ports that use the newer GO-I fixes, and there are more in the PR https://github.com/macports/macports-ports/pull/9609 for Poppler. That said, the lead GO-I owner has requested a moratorium on most changes to ports that use GO-I, to give time to update GO-I to the current version. Once that's done, the rev-bumps will be required, both for the updated GO-I as well as for any tweaks required to fix the GIR issue if it still exists.

comment:25 Changed 6 weeks ago by michaelld (Michael Dickens)

Resolution: fixed
Status: reopenedclosed

In 6ac80db669b581f98e8e99b81b23de875ae57a51/macports-ports (master):

various: rev-bump to fix gobject-introspection build issues

+ mostly with GNU Radio, but probably other ports too

Closes: #61699
Closes: #61508

comment:26 Changed 6 weeks ago by michaelld (Michael Dickens)

I rev-bumped some of these ports to fix this issue. It might not get every single last one, but it gets critical ones with other tickets open. Not all GO-I dependent ports require a rev-bump; let's do those as needed moving forward ... might not be any more than I just did, who knows?

Note: See TracTickets for help on using tickets.