Since libgit2 update to 1.9.0 from the binhost, my system has preserved libs because of cargo-c requiring 1.8.4. This has prevented me from running emerge --depclean so I decided to run emerge @preserved_libs which downgraded libgit2 and caused 3 rebuilds, one of them being dev-vcs/gitg-44-r1. However gitg broke with: ``` meson.build:157:0: ERROR: Assert failed: please recompile a threadsafe version of libgit2 (-DTHREADSAFE:BOOL=ON) ``` I checked libgit2 and it was built with threads, but then this use flag had no reference inside the ebuild or inherited eclasses whatsoever aside from the IUSE line in the ebuild. I also traced it back to this commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/libgit2?id=42b4b58e90debc30cf85cc01b9a5d5849a2c2ce1 Which does not explain dropping -DTHREADSAFE from cmake arguments nor it makes any reference to a bug that would.
It was removed from the ebuild because this option been gone from libgit2 since 2021[1] and USE_THREADS is enabled by default (no need to pass it). Haven't tried to build that package and I don't know why it's showing that error at a glance. Either that package is doing some failed detection is "thinking" it's due to threading support, or something unexpected is up with your libgit2. [1] https://github.com/libgit2/libgit2/commit/9324d16e73
(In reply to Ionen Wolkens from comment #1) > It was removed from the ebuild because this option been gone from libgit2 > since 2021[1] and USE_THREADS is enabled by default (no need to pass it). (the IUSE=threads serve no purpose though, seems to be a left-over -- aka threading support should be *enabled* regardless of if that USE is set or not)
I decided to update again from the binhost so that I can reproduce the issue and gather proper logs and here's what happened:
Created attachment 922756 [details] libgit2 update log
gitg's meson.build performs this test to check that GGIT_FEATURE_THREADS is enabled in the value returned from ggit_get_features(). > ggit_threads = ''' > #include <libgit2-glib/ggit.h> > int > main(int argc, const char *argv[]) > { > ggit_init (); > return ((ggit_get_features () & GGIT_FEATURE_THREADS) != 0) ? 0 : 1; > }; > ''' > > res = cc.run(ggit_threads, dependencies: libgit2_glib_dep) > assert( > res.compiled() and (res.returncode() == 0), > 'please recompile a threadsafe version of libgit2 (-DTHREADSAFE:BOOL=ON)', > )
1.8.4 both source based and from binhost is OK, 1.9.0 both source based and from binhost breaks gitg. I think I've covered all cases in the following logs:
Created attachment 922775 [details] Build logs from different combinations of libgit2 and gitg The leading numbers show the sequence in which I conducted the installations.
As a test, install libgit2-1.9.0 and compile/run the following program (link with -lgit2). > #include <stdio.h> > #include <git2.h> > > int main(void) { > int features = git_libgit2_features(); > if (features & GIT_FEATURE_THREADS) > puts("threads enabled"); > else > puts("threads disabled"); > return 0; > }
(In reply to Mike Gilbert from comment #8) > As a test, install libgit2-1.9.0 and compile/run the following program (link > with -lgit2). It returns threads enabled. However I tried to compile the code snippet in c#5 and it returned: > fatal error: libgit2-glib/ggit.h: No such file or directory > 1 | #include <libgit2-glib/ggit.h> > | ^~~~~~~~~~~~~~~~~~~~~ > compilation terminated. p.s. consider using another notation for posting sample code on the bug tracker. Not that removing >'s is hard but it's inconvenient.
Ok, with the help of pkg-config I figured what flags I should pass to gcc and tested that snippet successfully on 1.8.4 ``` $ ./test1 ~/libgit2 $ echo $? 0 ``` and unsuccessfully on 1.9.0: ``` $ gcc test1.c -o test1 -lgit2-glib-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgit2 -I/usr/include/libgit2-glib-1.0 -DGIT_SSH=1 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread -I/usr/lib64/libffi/include In file included from /usr/include/libgit2-glib-1.0/libgit2-glib/ggit-annotated-commit.h:28, from /usr/include/libgit2-glib-1.0/libgit2-glib/ggit.h:24, from test1.c:1: /usr/include/libgit2-glib-1.0/libgit2-glib/ggit-types.h:26:10: fatal error: ggit-types-19.h: No such file or directory 26 | #include "ggit-types-19.h" | ^~~~~~~~~~~~~~~~~ compilation terminated. ``` It looks like something changed in libgit2 that was notreflected in gitg. This is.
For some reason ggit-types-19.h from libgit2-glib is not installed although it's in the build tree: ``` # ebuild /var/db/repos/gentoo/dev-libs/libgit2-glib/libgit2-glib-1.2.1.ebuild install ... >>> Completed installing dev-libs/libgit2-glib-1.2.1 into /var/tmp/portage/dev-libs/libgit2-glib-1.2.1/image ... # find /var/tmp/portage/dev-libs/libgit2-glib-1.2.1/work/ -name ggit-types-19.h /var/tmp/portage/dev-libs/libgit2-glib-1.2.1/work/libgit2-glib-1.2.1/libgit2-glib/ggit-types-19.h # find /var/tmp/portage/dev-libs/libgit2-glib-1.2.1/image/ -name ggit-types-19.h <no output> ``` ggit-types-18.h and ggit-types-19.h were introduce in this commit: https://gitlab.gnome.org/GNOME/libgit2-glib/-/commit/9c3002bd2f1594901e7d8c2c0edc5c7ce30a9a76 which is part of libgi2-glib-1.2.1 already, but only ggit-types-18.h gets installed. I have no explanation for that. There isn't in the ebuild, nor there are any patches to remove -19.h.
(In reply to Georgi from comment #11) > For some reason ggit-types-19.h from libgit2-glib is not installed although > it's in the build tree: Seems like it picks which to install based on what major version of libgit2 libgit2-glib was built against. Aka, if built with 1.8.4 it'll install -18.h, if built with 1.9.0 then it installs -19.h
Considering libgit2-glib is missing a binding := on libgit2 and rebuilds have to wait for @preserved, it's possible there's weird interaction with that but I haven't really looked at this issue closely.
(In reply to Ionen Wolkens from comment #13) > Considering libgit2-glib is missing a binding := on libgit2 and rebuilds > have to wait for @preserved, it's possible there's weird interaction with > that but I haven't really looked at this issue closely. fwiw I did give dev-vcs/gitg a build using libgit-1.9.0 and it built fine for me, albeit I do have types-19.h installed (and types-18.h isn't), and do not have any pending @preserved-rebuild.
(In reply to Ionen Wolkens from comment #12) > (In reply to Georgi from comment #11) > > For some reason ggit-types-19.h from libgit2-glib is not installed although > > it's in the build tree: > Seems like it picks which to install based on what major version of libgit2 > libgit2-glib was built against. > > Aka, if built with 1.8.4 it'll install -18.h, if built with 1.9.0 then it > installs -19.h Problem is: ``` Sun 23 Mar 2025 12:53:59 PM EET: >>> emerge (3 of 31) dev-libs/libgit2-1.9.0 to / Sun 23 Mar 2025 12:53:59 PM EET: === (3 of 31) Merging Binary (dev-libs/libgit2-1.9.0::/var/cache/binpkgs/dev-libs/libgit2-1.9.0.gpkg.tar) Sun 23 Mar 2025 12:54:03 PM EET: >>> unmerge success: dev-libs/libgit2-1.8.4 ... Sun 23 Mar 2025 12:58:17 PM EET: >>> emerge (15 of 31) dev-libs/libgit2-glib-1.2.1 to / Sun 23 Mar 2025 12:58:31 PM EET: >>> unmerge success: dev-libs/libgit2-glib-1.2.0-r2 ``` The above log is a bit filtered and piped through awk to convert timestamps, but essentially the fact that I don't see Mergin Binary line for libgit2-glib means it built locally against libgit2-1.9.0 as they were updated in the same session.
(In reply to Georgi from comment #15) Disregard that. Now I understand that at the stage of things in the first post libgit2-glib was built against libgit2-1.9.0 from the binhost and that's why gitg from emerge @preserved_libs failed as it needed ggit-types-18.h but since libgit2-glib was not rebuilt against libgit2-1.8.4 it was missing. So your suspicion of missing binding := must be right.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=750ca9b4871e7156d92771d2530647808c7f76ff commit 750ca9b4871e7156d92771d2530647808c7f76ff Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2025-03-26 10:38:45 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2025-03-26 10:40:46 +0000 dev-libs/libgit2-glib: add missing binding operator for libgit2 Haven't looked at bug #952063 in-depth but sounds like that this should fix it so tentatively closing. Either way, this := should be there. Closes: https://bugs.gentoo.org/952063 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../{libgit2-glib-1.2.1.ebuild => libgit2-glib-1.2.1-r1.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
ftr, seems the binding operator was accidentally lost when this range was removed (by adding the [ssh?] to the lower one and removing the first): <dev-libs/libgit2-1.9:=[ssh?] >=dev-libs/libgit2-0.26.0
I'm sorry about that, my mistake indeed.
(In reply to Georgi from comment #9) > p.s. consider using another notation for posting sample code on the bug > tracker. Not that removing >'s is hard but it's inconvenient. It's the only way to prevent bugzilla from wrapping lines.
