gobject-introspection generates invalid gir files on Big Sur

[idryzhov (Igor Ryzhov)]

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

[ryandesign (Ryan Schmidt)]

#61571 might be the same problem.

[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...

[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>

[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.

[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....

[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.

[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.

[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

[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.

[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@…>

[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.

[rseichter (Ralph Seichter)]

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"

[jmroot (Joshua Root)]

Do the affected dependent ports need to be rev bumped?

[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.

[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.

[michaelld (Michael Dickens)]

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

[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?