tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Help with attempt to update devel/gdb (currently in wip/gdb)



Dear all,

I face the need for a serious update of devel/gdb, which is far too old
to even work with the system libraries of a current Debian stable
system (gives errors about unknown binary features).

Debian's gdb is at 13.1. From pkgsrc, I'd get 10.1. Current is 16.2.

So I tried to update it to 16.2. This attempt seems to work at least on
an Ubuntu system with gcc 11 in the base system, but I face some issues
interacting with my on-top-toolchain through the pkgsrc build
infrastructure. The final link errors out like this:

  CXX    init.o
  CXXLD  gdb
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
make[2]: *** [Makefile:2236: gdb] Error 1

If I re-run that linker command with --tag=CXX, I get another weird
error which I find being discussed deep in libtool history. I imagine
some nasty interaction with the pkgsrc build wrappery and my toolchain.
Is this inability to infer tagged configurations something known from
wrangling with build infrastructure in pkgsrc?

The build works fine for the outdated gdb-10.1 build in pkgsrc and the
same toolchain setup.

Apart from any build issues, things probably need to be cleaned up, for
example with outdated (unnecessary? missing?) SUBSTs and the question of
supporting Python versions. Maybe a default py3 is just fine?

Is there anyone with some interest in using gdb from pkgsrc, actually?
The age of the package suggests otherwise … or maybe it is just fine
that way for all platforms besides Linux/glibc.

Maybe you can comment on the attempted changes, help bring things into
shape so that I can merge it into pkgsrc main again. Probably after
having wip/gdb tested on some platforms. Anyone in the know: feel free
to hack on wip/gdb directly.

Pointing out obvious issues in the initial diff below in a reply is
also welcome. I realize that I probably messed up the REPLACE_BASH vs.
REPLACE.envbash part (cargo-coding) … would simple REPLACE_BASH itself
be enough to replace the #!/usr/bin/env bash lines? 

diff -ruN -x CVS devel/gdb/Makefile wip/gdb/Makefile
--- devel/gdb/Makefile	2024-01-27 14:56:37.000000000 +0100
+++ wip/gdb/Makefile	2025-04-22 23:07:40.599013795 +0200
@@ -1,18 +1,24 @@
 # $NetBSD: Makefile,v 1.82 2024/01/27 13:56:37 mef Exp $
 
-DISTNAME=	gdb-10.1
-PKGREVISION=	6
+# Work in Progress to update from anciend base version.
+# Right now it could work on plain Linux, but gives weird
+# linker error with custom toolchain (maybe also with gcc
+# from pkgsrc?). PLIST might need work, as does the Python
+# part. How much does it care about Python version?
+
+DISTNAME=	gdb-16.2
 CATEGORIES=	devel
 MASTER_SITES=	${MASTER_SITE_GNU:=gdb/}
 
 MAINTAINER=	pkgsrc-users%NetBSD.org@localhost
-HOMEPAGE=	https://www.gnu.org/software/gdb/gdb.html
+HOMEPAGE=	https://sourceware.org/gdb/
 COMMENT=	Symbolic debugger for multiple language frontends
 LICENSE=	gnu-gpl-v3
 
 NOT_FOR_PLATFORM+=	Darwin-*-aarch64
 
-USE_LANGUAGES=		c gnu++11
+USE_LANGUAGES=		c c++
+USE_CXX_FEATURES+=      c++17
 
 BROKEN_GETTEXT_DETECTION=	yes
 GNU_CONFIGURE=			yes
@@ -29,6 +35,11 @@
 # wants ncurses.h
 FAKE_NCURSES=			yes
 
+REPLACE_INTERPRETER+=   envbash
+REPLACE.envbash.old=    '/usr/bin/env\ bash'
+REPLACE.envbash.new=    ${PREFIX}/bin/bash
+REPLACE_FILES.envbash=  gdb/gcore.in gdb/gstack-1.in
+
 # In gdb/configure, depcomp is parsed with sed.
 SUBST_CLASSES+=			fix-depcomp
 SUBST_STAGE.fix-depcomp+=	pre-configure
@@ -38,8 +49,7 @@
 SUBST_FILES.fix-depcomp+=	gnulib/configure libctf/configure
 SUBST_SED.fix-depcomp+=		-e 's,< ./depcomp,${_OVERRIDE_PATH.depcomp},'
 
-CONFIGURE_ARGS+=	--disable-binutils
-CONFIGURE_ARGS+=	--disable-gprof
+CONFIGURE_ARGS+=	--disable-gprofng
 CONFIGURE_ARGS+=	--disable-gold
 CONFIGURE_ARGS+=	--disable-gas
 CONFIGURE_ARGS+=	--disable-ld
@@ -50,9 +60,6 @@
 
 .include "../../mk/bsd.prefs.mk"
 
-REPLACE_BASH+=		gdb/gcore.in
-REPLACE_BASH+=		sim/testsuite/sim/bfin/run-tests.sh
-
 PLIST_VARS+=	gcore
 .if (${OPSYS} == "SunOS" || ${OPSYS} == "NetBSD" \
     || ${OPSYS} == "Linux" || ${OPSYS} == "FreeBSD")
@@ -80,7 +87,8 @@
 
 post-extract:
 	${MKDIR} ${WRKDIR}/build
-
+.include "../../math/mpfr/buildlink3.mk"
+.include "../../devel/gmp/buildlink3.mk"
 .include "../../mk/termcap.buildlink3.mk"
 .include "../../devel/gettext-lib/buildlink3.mk"
 .include "../../mk/bsd.pkg.mk"
diff -ruN -x CVS devel/gdb/options.mk wip/gdb/options.mk
--- devel/gdb/options.mk	2020-10-24 20:22:08.000000000 +0200
+++ wip/gdb/options.mk	2025-04-22 22:47:03.120543202 +0200
@@ -9,7 +9,7 @@
 
 .if !empty(PKG_OPTIONS:Mpython)
 CONFIGURE_ARGS+=	--with-python=${PYTHONBIN}
-PYTHON_VERSIONS_ACCEPTED=	 27 # Newer supported, but needs more tweaking
+#PYTHON_VERSIONS_ACCEPTED=	 27 # Newer supported, but needs more tweaking
 .include "../../lang/python/application.mk"
 PLIST.python=	yes
 .endif

[skipping changed patches and PLIST, see wip/gdb]


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg


Home | Main Index | Thread Index | Old Index