Created attachment 209816 [details] libgtop build error This is necessary to build GNOME 3 on 13-CURRENT r355560 Error log attached.
I have a patch, but am still waiting for my laptop to recompile GNOME. Since I have a reasonably fast laptop, it should take about an hour or two (or less).
Created attachment 209828 [details] Patch: make devel/libgtop use left instead of next in struct vm_map_entry The issue started with commit r355491. https://freshbsd.org/commit/freebsd/src/355491 libgtop hasn't compiled (yet) on my laptop while I'm building GNOME, but I will report when it does (or update the patch if it doesn't). I don't know if this patch works on 11.x or 12.x.
This patch works, I can confirm it builds on my system.
(In reply to Neel Chauhan from comment #2) The commit you mentioned replaces most 'next' with 'right'. I didn't carefully read the commit, but I doubt if replacing 'next' with 'left' is correct here. Since the problem is very likely to exist the upstream project, it is recommended to report it to the upstream (https://gitlab.gnome.org/GNOME/libgtop) as well.
Good catch. I have been using LXQt while GNOME was broken. I'm recompiling GNOME right now, with the new libgtop patch.
Created attachment 209957 [details] Patch: make devel/libgtop use right instead of next in struct vm_map_entry You're right. I was able to get Gnome working. Thanks!
Created attachment 209975 [details] Patch: make devel/libgtop use right instead of next in struct vm_map_entry (Revision 3) This also allows compatibility with FreeBSD 11.x and 12.x using the old syntax.
This patch was merged to the GNOME libgtop repo. Also, thank you @Ting-Wei Lan for suggesting this. Still no response from the Ports people.
Proof: https://gitlab.gnome.org/GNOME/libgtop/commit/9b4a03ed0a82a3cbd3086e5352a991759213471b
Comment on attachment 209975 [details] Patch: make devel/libgtop use right instead of next in struct vm_map_entry (Revision 3) Why existing patch (from ports r422756) was clobbered? If no longer required it should be removed in a separate change after testing runtime.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242620#c5
Created attachment 210008 [details] Patch: make devel/libgtop use right instead of next in struct vm_map_entry (Revision 3) In https://reviews.freebsd.org/D21964, the Revision 3 logic is incorrect. I fixed this.
Created attachment 210013 [details] Patch: make devel/libgtop use right instead of next in struct vm_map_entry
Created attachment 210019 [details] Patch: make devel/libgtop use right instead of next in struct vm_map_entry (Revision 6) This patch incorporates dougm@'s changes from here: https://reviews.freebsd.org/D21964/new/#500455 I abandoned my patch in favor of his.
An updated patch is available on Phabricator: https://reviews.freebsd.org/D22929
Created attachment 210610 [details] Updated patch for r356432 and later r356432 on head [1] broke this again by eliminating v_tag from struct vnode. r356437 on head [2] fixes by replacing v_tag with v_lock.lock_object.lo_name. Attached patch is the update for the one on phablicator D22929. Unfortunately, I'm not enough familiar with phablicator to update diff there. Beware! Not enogh confirmed whether additional __FreeBSD_version checking is required or not. [1] https://lists.freebsd.org/pipermail/svn-src-head/2020-January/132472.html [2] https://lists.freebsd.org/pipermail/svn-src-head/2020-January/132477.html
Created attachment 210676 [details] Rebase patch after ports r522841 ports r522841 was committed in the meantime, so rebase attachment 210610 [details]. Builds and runs on base r356590. __FreeBSD_version was bumped at base r356409 and base r356511, so checking that wouldn't work.
A commit references this bug: Author: kwm Date: Mon Jan 13 19:02:55 UTC 2020 New revision: 522971 URL: https://svnweb.freebsd.org/changeset/ports/522971 Log: Commit the correct patch. PR: 242533 Submitted by: Neel Chauhan <neel AT neelc DOT org> Pointyhat to: kwm@ Changes: head/devel/libgtop/files/patch-sysdeps_freebsd_procmap.c
Thanks for everyone involved making this patch great. Although I could have done without committing the old version..