glib2, glib2-devel @2.80.0 conflicts with gobject-introspection

[barracuda156]

Error: Failed to activate glib2-devel: Image error: /opt/local/lib/girepository-1.0/GLib-2.0.typelib is being used by the active gobject-introspection port.  Please deactivate this port first, or use 'port -f activate glib2-devel' to force the activation.

[barracuda156]

gobject-introspection-devel installed fine with the new glib2-devel, so incompatibility seems to only apply to a combo of devel and non-devel versions.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #69749.

[andlabs (Pietro Gagliardi)]

I do not have either -devel package installed and still get the error on upgrade. (In fact, I had recently wiped and reinstalled MacPorts from scratch, due to other accumulated issues.)

Pietros-MBP:_ pietro$ sudo port echo installed|egrep 'glib|gobject'
glib2                          @2.78.4_0+quartz 
glib2                          @2.80.0_0+quartz 
gobject-introspection          @1.78.1_2 
Pietros-MBP:_ pietro$ 

Right now I have @2.78.4_0+quartz manually reactivated to keep my glib-dependent packages working. These were built with -x11 +no_x11 +quartz in variants.conf but with no other variants AFAIK.

[mascguy (Christopher Nielsen)]

Has duplicate issue:69750

[mascguy (Christopher Nielsen)]

CCing others, from downstream issue #69751

[mascguy (Christopher Nielsen)]

For anyone interested in the technical details/background: For version 1.80.x, some core introspection-related components were migrated between gobject-introspection and glib2.

And due to the changes, it looks like - and still working to confirm this - that glib2 now requires a two-step installation process. Still trying to wrap my head around the details, but thus far, the tentative approach looks like it might be something like:

• First glib2 must be built with introspection disabled
• Then gobject-introspection is built
• And finally, glib2 must be built again with introspection enabled.

There's nothing for anyone else to do at this point though, as this all needs to be handled by our ports for glib2 and gobject-introspection.

In any case, I'm presently reviewing what's being done by Linux distributions, to determine the best pattern to use.

Suffice it to say, this is my top priority at the moment, given the potential user impact. And hoping to resolve this within the next 24 hours or less, to minimize that.

More to follow, as everything becomes more clear...

[MrB74]

Also impacted are ports like podofo/podofo-0.10, poppler, harfbuzz

[thetrial (alabay)]

Logfile for +universal, built under 10.12.6.

[thetrial (alabay)]

glib2                          @2.78.4_0+universal+x11
gobject-introspection          @1.78.1_2+universal

I have problems, too. But I’m not quite sure if it has to do with the mentioned here. I see lots of Unknown namespace for symbol. My variant is +universal. I’ll add the logfile. I’m under 10.12.6.

[ryandesign (Ryan Carsten Schmidt)]

That's a different problem:

ld: warning: ignoring file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/glib/libglib-2.0.dylib, file was built for i386 which is not the architecture being linked (x86_64): /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/glib/libglib-2.0.dylib
ld: warning: ignoring file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/gobject/libgobject-2.0.dylib, file was built for i386 which is not the architecture being linked (x86_64): /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/gobject/libgobject-2.0.dylib
ld: warning: ignoring file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/gio/libgio-2.0.dylib, file was built for i386 which is not the architecture being linked (x86_64): /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/gio/libgio-2.0.dylib
ld: warning: ignoring file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/gmodule/libgmodule-2.0.dylib, file was built for i386 which is not the architecture being linked (x86_64): /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/work/build-i386/gmodule/libgmodule-2.0.dylib

It's building i386 (as you requested by asking for the universal variant), then trying to link x86_64 which of course fails. It should be linking for i386 as well. File a new ticket please.

[dragos-bth (Dragos Ilie)]

texlive impacted as well (due to poppler)

[wyuenho (Jimmy Yuen Ho Wong)]

Can we revert the change and bump the epoch first if this issue can't be fixed quickly?

[christophecvr (christophecvr)]

gtk3 is also affected many many packages needs rebuild when building for quartz only. Complete failure for atk,harbuzz and ... all same issue Couldn't find include 'GObject-2.0.gir' . Tried the trick above with removing introspection build glib2 and then again with introspection. No change. (glib2 with quartz) . Build by me is on macbookpro mid 2010 so blocked at High Sierra (10.13.6) . Build without legacy support and disabled macports wide universal support. core is fully x86_64 so i386 is nuisance for this mac.

[Gandoon (Erik Hedlund)]

Now I am getting a bit confused as I initially also had something similar to this issue, but how I solved it was that I did end up force activating glib2 @2.80.0_0+quartz, cleaning up the leftovers, and then upgrading to gobject-introspection @1.80.1_0. It seems to have worked, but judging from others also having issues I am unsure if everything is healthy. At least I don't have any linking errors or similar.

I thought I just ended up building them in the "wrong order" and having the old gobject-introspection @1.78.1_2 active was what triggered the issue, but maybe it was a bit more involved.

[christophecvr (christophecvr)]

Replying to christophecvr:

gtk3 is also affected many many packages needs rebuild when building for quartz only. Complete failure for atk,harbuzz and ... all same issue Couldn't find include 'GObject-2.0.gir' . Tried the trick above with removing introspection build glib2 and then again with introspection. No change. (glib2 with quartz) . Build by me is on macbookpro mid 2010 so blocked at High Sierra (10.13.6) . Build without legacy support and disabled macports wide universal support. core is fully x86_64 so i386 is nuisance for this mac.

Oeps sorry I did not noticed but now I did the suggested procedure by mascguy (Christopher Nielsen)

I just added a variant introspection into port file glib2. I set by configure.args-append -Dintrospection=disabled.

The variant introspection change this back to enabled. Uninstall gobject-instrospection (with -f) same for glib 2. Then installed glib2 with:

sudo port -s -v install glib2 +quartz

Then glib 2 was installed without introspection. then

sudo port install -s -v gobject-introspection

Then installed glib a second time by:

sudo port -s -v install glib2 +quartz +introspection

now glib2 is installed with introspection and indeed the :

/opt/local/share/gir-1.0/GObject-2.0.gir

Is indeed installed.

All packages are now building fine atk,harbuzz and ...

[mrdomino (Jōshin)]

For me just now (with glib2 at 2.80.0_0 and gobject-introspection at 1.80.1_0) it was enough to do port uninstall -f glib2 gobject-introspection followed by port install glib2 gobject-introspection.

[mrdomino (Jōshin)]

Ah, however, now while trying to update poppler I get:

:info:build Couldn't find include 'GObject-2.0.gir' (search path: '['/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-24.04.0/glib', '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/.home/.local/share/gir-1.0', 'gir-1.0', '/usr/local/share/gir-1.0', '/usr/share/gir-1.0', '/opt/local/share/gir-1.0', '/opt/local/share/gir-1.0', '/usr/share/gir-1.0']')

[eirnym (Eir Nym)]

this issue also impacts pango => ffmpeg6 => mpv

[christophecvr (christophecvr)]

Replying to mrdomino:

Ah, however, now while trying to update poppler I get:

:info:build Couldn't find include 'GObject-2.0.gir' (search path: '['/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-24.04.0/glib', '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/.home/.local/share/gir-1.0', 'gir-1.0', '/usr/local/share/gir-1.0', '/usr/share/gir-1.0', '/opt/local/share/gir-1.0', '/opt/local/share/gir-1.0', '/usr/share/gir-1.0']')

Yes this was at first by me also. You need to do it like I just explained change you're portfile and create a variant introspection. There are maybe outher ways but that is the only I found.

add to port file : the -Dintrospection=disabled

configure.args-append \
                            -Ddefault_library=both \
                            -Dlibelf=enabled \
                            -Dlibmount=disabled \
                            -Dwarning_level=0 \
                            -Dintrospection=disabled

then create variant in port file

variant introspection {
    configure.args-replace \
        -Dintrospection=disabled \
        -Dintrospection=enabled
}

and use it as explained.

[eirnym (Eir Nym)]

According to internet search (google, ddg, etc), all package systems has been failed with this change in glib2/gobject-introspection. I believe core developers thought that system has already gobejct-introspection library installed and they didn't check other applications.

Could somebody ping core developers? I believe it's worth a while to let them know what mess they have been made.

[mascguy (Christopher Nielsen)]

Replying to eirnym:

According to internet search (google, ddg, etc), all package systems has been failed with this change in glib2/gobject-introspection. I believe core developers thought that system has already gobejct-introspection library installed and they didn't check other applications.

Could somebody ping core developers? I believe it's worth a while to let them know what mess they have been made.

Let's try to avoid criticizing upstream. My only complaint is that the release notes didn't shout this out more clearly, as it's not immediately clear from either project how much things changed for 1.80.x. But otherwise, Linux distribution and such seem to have this figured out, so this is on me.

[Behinder (behinder)]

There should be separate place in hell for people doing such breaking maneuvers between packages.

[mascguy (Christopher Nielsen)]

Replying to Behinder:

There should be separate place in hell for people doing such breaking maneuvers between packages.

Upstream has the best of intentions, and I suspect this is something they've wanted to do for a long time. (It was simply a matter of when to do it, and it's one of those things that needed to be done.) Presumably this improves things for the longer-term, allows them to clean things up, etc.

[Christopher Nielsen <mascguy@…>]

In 3dd0371d5300b460018835187d11d7e546400a91/macports-ports (master):

glib2{,-devel}: revert to 2.78.0

See: #69748

[Christopher Nielsen <mascguy@…>]

In 27232840c3a17c40c3b3237b0b1113ddd2d8b250/macports-ports (master):

gobject-introspection{,-devel}: revert to 1.78.1

See: #69748
Fixes: #69105

[Christopher Nielsen <mascguy@…>]

In 007b1d72777252a304ca420b1b30ee6f394fa78f/macports-ports (master):

glibmm{,-devel}: revert to 2.78.0

See: #69748
See: #65859

[Christopher Nielsen <mascguy@…>]

In f3fc6479816a197717d85e86a64106a8798acf3f/macports-ports (master):

glib2 dependents: rev-bump after downgrade

See: #69748

[christophecvr (christophecvr)]

Well guess I stay with previous version. With the rebuild you proposed as solution and when you do this right by adapting the glib2 port we can continu to build and I guess it will be just the wait on a upstream upgrade.

[thetrial (alabay)]

Replying to ryandesign:

That's a different problem:

[…]

It's building i386 (as you requested by asking for the universal variant), then trying to link x86_64 which of course fails. It should be linking for i386 as well. File a new ticket please.

Done: #69771. Thank you.

[barracuda156]

Replying to Christopher Nielsen <mascguy@…>:

It looks like some ports are still broken.

Are we to expect a fixed new version soon? If yes, I will not bother with revbumping.

16. S. Need to review in fact more closely, maybe those ports were built locally with a newer glib2 and friends, but in the master there is no issue.

[mascguy (Christopher Nielsen)]

Replying to barracuda156:

It looks like some ports are still broken.

I'm not planning to update glib2 again anytime soon.

So which ports are still broken?

And did you allow the rev-bump3d ports to rebuild?

[lukaso (Lukas Oberhuber)]

I think there might still be problems with gobject-introspection. I don't really know for sure but my builds of GIMP are failing: ​https://gitlab.gnome.org/GNOME/gimp/-/issues/11361

With this:

--- stderr ---
error: /Library/Developer/CommandLineTools/usr/bin/install_name_tool: can't create output file: /Users/circleci/macports-gimp3-arm64/lib/libgirepository-1.0.dylib.XXXXXX (Operation not permitted)
fatal error: /Library/Developer/CommandLineTools/usr/bin/install_name_tool: cannot rename /Users/circleci/macports-gimp3-arm64/lib/libgirepository-1.0.1.dylib to /Users/circleci/macports-gimp3-arm64/lib/libgirepository-1.0.dylib.XXXXXX (No such file or directory)

It looks very reminiscent of #63641

[mascguy (Christopher Nielsen)]

Replying to lukaso:

I think there might still be problems with gobject-introspection. I don't really know for sure but my builds of GIMP are failing: ​https://gitlab.gnome.org/GNOME/gimp/-/issues/11361

With this:

--- stderr ---
error: /Library/Developer/CommandLineTools/usr/bin/install_name_tool: can't create output file: /Users/circleci/macports-gimp3-arm64/lib/libgirepository-1.0.dylib.XXXXXX (Operation not permitted)
fatal error: /Library/Developer/CommandLineTools/usr/bin/install_name_tool: cannot rename /Users/circleci/macports-gimp3-arm64/lib/libgirepository-1.0.1.dylib to /Users/circleci/macports-gimp3-arm64/lib/libgirepository-1.0.dylib.XXXXXX (No such file or directory)

It looks very reminiscent of #63641

For others CCed on this ticket, have you been able to successfully update since we fixed all of this?

[lukaso (Lukas Oberhuber)]

Yes, this was a “from scratch” build after the versions had been reverted (if that’s what is meant by “fixed all this”).

[lukaso (Lukas Oberhuber)]

Gimp failing to build because of install_name_tool issue with gobject-introspection

[mascguy (Christopher Nielsen)]

Replying to lukaso:

Yes, this was a “from scratch” build after the versions had been reverted (if that’s what is meant by “fixed all this”).

Sure, understood. But ultimately I need to know whether this same issue is also affecting others, to determine where to start digging.

[lukaso (Lukas Oberhuber)]

I realized after I posted it that it sounded a bit snarky. Wasn’t meant that way, and sorry if it came across that way. This has been a tricky beast!

[MrB74]

I did a full from zero reinstall and rebuild. All ok

[lukaso (Lukas Oberhuber)]

The GIMP problem looks like it was on the GIMP side, so all clear from me as well.

[eirnym (Eir Nym)]

Replying to mascguy:

Replying to eirnym:

According to internet search (google, ddg, etc), all package systems has been failed with this change in glib2/gobject-introspection. I believe core developers thought that system has already gobejct-introspection library installed and they didn't check other applications.

Could somebody ping core developers? I believe it's worth a while to let them know what mess they have been made.

Let's try to avoid criticizing upstream. My only complaint is that the release notes didn't shout this out more clearly, as it's not immediately clear from either project how much things changed for 1.80.x. But otherwise, Linux distribution and such seem to have this figured out, so this is on me.

I respect your point, but I see exactly the same discussion in just every distro for this particular version (as ddg/google shows in their results). Linux distributions has "figured this out", as 99% of users will just download pre-built binaries, and other 1% will read mailing lists of respective distributions. If port/package maintainters won't notify developers, there's a chance, that they won't notice it at all.

The dependency cycle clearly be a result of an improper refactoring, when tools were already pre-installed on all machines and developers were just trying to rebuild libraries even on CI. I see it as a misuse of current build environment and testing of upgrade only without a package manager (e.g. make install) vs clean install.