Per title. Attached emerge --info and build log.
Created attachment 913738 [details] emerge --info
Created attachment 913739 [details] build log
Summary to fix: comment out the import, adjust references further down the file, and `emerge -1 dev-libs/gobject-introspection`. I had the same error (with glib and with other packages). With `equery b` you can see that the offending file /usr/lib64/gobject-introspection/giscanner/ccompiler.py is owned by dev-libs/gobject-introspection. I tried updating that package first with `emerge -1 dev-libs/gobject-introspection`, but it starts building glib first. Because MVSCCompiler (Microsoft Visual C/C++ Compiler) isn't relevant for Gentoo, I decided that commenting out the offending import and adjusting the references further down the file wouldn't hurt. glib and gobject-introspection have built succesfully, overwriting /usr/lib64/gobject-introspection/giscanner/ccompiler.py so my hotfix has been erased and in the new version MVSCCompiler has been removed from the file altogether.
(For completeness, I updated to =dev-libs/gobject-introspection-1.82.0-r1)
(In reply to Midgard from comment #3) > Summary to fix: comment out the import, adjust references further down the > file, and `emerge -1 dev-libs/gobject-introspection`. > > I had the same error (with glib and with other packages). With `equery b` > you can see that the offending file > /usr/lib64/gobject-introspection/giscanner/ccompiler.py is owned by > dev-libs/gobject-introspection. I tried updating that package first with > `emerge -1 dev-libs/gobject-introspection`, but it starts building glib > first. Because MVSCCompiler (Microsoft Visual C/C++ Compiler) isn't relevant > for Gentoo, I decided that commenting out the offending import and adjusting > the references further down the file wouldn't hurt. glib and > gobject-introspection have built succesfully, overwriting > /usr/lib64/gobject-introspection/giscanner/ccompiler.py so my hotfix has > been erased and in the new version MVSCCompiler has been removed from the > file altogether. Just attempted your workaround, but I got the same failure. Perhaps I missed a couple lines.
I don't yet get what's happening here. https://gitlab.gnome.org/GNOME/gobject-introspection/-/commit/a2139dba59eac283a7f543ed737f038deebddc19 is in 1.82.0. When hitting this, what version of gobject-introspection is installed? i.e. Please show emerge -pvO dev-libs/glib dev-libs/gobject-introspection.
OK, I get it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cfe67c6d2d4e15989aa16764a92c36e284457712 commit cfe67c6d2d4e15989aa16764a92c36e284457712 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-12-14 15:55:15 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-14 15:57:40 +0000 dev-libs/glib: fix finding just-built g-ir-scanner Without PKG_CONFIG_PATH having the just-built paths prepended, meson will find binaries from gobject-introspection on the system instead which may be: a) old (which is a problem anyway, unclear if that's guaranteed to work, and weird given we just built one), or b) too old (where gobject-introspection on the system is older than the fixed versions for bug #865183) Fix that by prepending the right paths. Bug: https://bugs.gentoo.org/865183 Closes: https://bugs.gentoo.org/946221 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/glib/glib-2.80.5.ebuild | 5 ++++- dev-libs/glib/glib-2.82.2.ebuild | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-)
Just ran into the same error with dev-libs/glib-2.82.4. Is there something that needs to be done prior to emerging this package?
(In reply to Russell Dwiggins from comment #9) > Just ran into the same error with dev-libs/glib-2.82.4. > > Is there something that needs to be done prior to emerging this package? No, it should work as-is. Please show me build.log + emerge --info.
Created attachment 914066 [details] build log for glib-2.82.4
Created attachment 914067 [details] emerge --info
Thanks. ``` Traceback (most recent call last): File "/var/tmp/portage/dev-libs/glib-2.82.4/temp/usr/lib64/pkgconfig/../../bin/g-ir-scanner", line 103, in <module> from giscanner.scannermain import scanner_main File "/usr/lib64/gobject-introspection/giscanner/scannermain.py", line 35, in <module> from giscanner.ast import Include, Namespace File "/usr/lib64/gobject-introspection/giscanner/ast.py", line 29, in <module> from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF File "/usr/lib64/gobject-introspection/giscanner/sourcescanner.py", line 25, in <module> from .ccompiler import CCompiler File "/usr/lib64/gobject-introspection/giscanner/ccompiler.py", line 29, in <module> from distutils.msvccompiler import MSVCCompiler ``` Note the first line is right, but then it loads the Python modules from the system. I'll look more.
Hmmmmmm, in g-ir-scanner: ``` # Detect and set datadir, pylibdir, etc as applicable # Similar to the method used in gdbus-codegen filedir = os.path.dirname(__file__) # Try using relative paths first so that the installation prefix is relocatable datadir = os.path.abspath(os.path.join(filedir, '..', 'share')) # Fallback to hard-coded paths if the relocatable paths are wrong if not os.path.isdir(os.path.join(datadir, 'gir-1.0')): datadir = "/usr/share" builtins.__dict__['DATADIR'] = datadir gir_dir = os.path.abspath(os.path.join(filedir, '..', 'share', 'gir-1.0')) # Fallback to hard-coded paths if the relocatable paths are wrong if not os.path.isdir(gir_dir): gir_dir = "/usr/share/gir-1.0" builtins.__dict__['GIR_DIR'] = gir_dir # Again, relative paths first so that the installation prefix is relocatable pylibdir = os.path.abspath(os.path.join(filedir, '..', 'lib', 'gobject-introspection')) ```
I wonder if this will ever work for Gentoo in the relocatable case: ``` # Again, relative paths first so that the installation prefix is relocatable pylibdir = os.path.abspath(os.path.join(filedir, '..', 'lib', 'gobject-introspection')) ``` It's at lib64 for you. Are you able to try a patch if I give you one shortly?
(In reply to Sam James from comment #15) > I wonder if this will ever work for Gentoo in the relocatable case: > ``` > # Again, relative paths first so that the installation prefix is relocatable > pylibdir = os.path.abspath(os.path.join(filedir, '..', 'lib', > 'gobject-introspection')) > ``` > > It's at lib64 for you. Are you able to try a patch if I give you one shortly? Yes. This evening or tomorrow.
Created attachment 914072 [details, diff] glib-hack.patch Can you apply this patch to the ebuild itself (i.e. modify the ebuild in /var/db/repos/gentoo)? (Not in /etc/portage/patches)
(In reply to Sam James from comment #17) > Created attachment 914072 [details, diff] [details, diff] > glib-hack.patch > > Can you apply this patch to the ebuild itself (i.e. modify the ebuild in > /var/db/repos/gentoo)? (Not in /etc/portage/patches) err, /usr/portage in your case.
(In reply to Sam James from comment #18) > (In reply to Sam James from comment #17) > > Created attachment 914072 [details, diff] [details, diff] [details, diff] > > glib-hack.patch > > > > Can you apply this patch to the ebuild itself (i.e. modify the ebuild in > > /var/db/repos/gentoo)? (Not in /etc/portage/patches) > > err, /usr/portage in your case. Thanks for the poke. I'll migrate this machine too. Will do ASAP.
(In reply to Sam James from comment #17) > Created attachment 914072 [details, diff] [details, diff] > glib-hack.patch > > Can you apply this patch to the ebuild itself (i.e. modify the ebuild in > /var/db/repos/gentoo)? (Not in /etc/portage/patches) Success!
Thank you!! I'll tidy this up into something proper and commit it later today.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c858ac4e4f97acc5a373e6de9191fe5e1b10e08c commit c858ac4e4f97acc5a373e6de9191fe5e1b10e08c Author: Sam James <sam@gentoo.org> AuthorDate: 2024-12-15 10:48:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-15 10:49:49 +0000 dev-libs/glib: further fixes for using just-built gobject-introspection g-ir-scanner has some relocatable logic but it searches for 'lib', not 'lib64', so it can't find itself and eventually falls back to the system installation. Followup to cfe67c6d2d4e15989aa16764a92c36e284457712. Closes: https://bugs.gentoo.org/946221 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/glib/glib-2.80.5.ebuild | 5 +++++ dev-libs/glib/glib-2.82.2.ebuild | 5 +++++ dev-libs/glib/glib-2.82.4.ebuild | 5 +++++ 3 files changed, 15 insertions(+)
*** Bug 946502 has been marked as a duplicate of this bug. ***
