Hallo!
Vor geschätzt gut einem Jahr hatte ich Schwierigkeiten beim Durchführen von "portupgrade devel/gdb6". Unter meinem System konnte ich das Ding nur mit einem Hack übersetzen und habe mal kurz bei dem zuständigen Maintainer nachgefragt. Nach seiner Aussage lies sich das Problem aber bei ihm nicht reproduzieren, und ich ließ die Sache auf sich beruhen.
Nun hatte ich aber gerade auf einem anderen Rechner dasselbe Problem und wollte mich mal umhören, ob es sich dabei immer nur um Einzelfälle handelt.
Hier eine kurze Beschreibung:
Beim Linken bricht "portupgrade devel/gdb6" mit dieser Fehlermeldung ab:
Anscheinend kann der Linker die Variable "readline_echoing_p" nicht finden, die in der Datei "/usr/ports/devel/gdb6/work/gdb-6.6/gdb/tui/tui-io.c" in der Funktion "void tui_setup_io (int mode)" durch "extern int readline_echoing_p" in der Zeile 508 deklariert wurde.
Im Netz habe ich unter http://bugs.gentoo.org/show_bug.cgi?id=259932 den Hinweis gefunden, daß der Fehler unter der Bedingung "sys-libs/readline" >= 6.0 (Linux-Pfad!) auftreten soll.
Beim Untersuchen meiner "libreadline" fiel mir damals folgendes auf:
Bei meinem alten Hack hatte ich probeweise in der "tui-io.c" den Namen an diese Variable angepaßt, zwar nicht systematisch getestet, aber es schien ersteinmal zu laufen.
<hinweis>
Bevor mich noch jemand für einen Hirni hält: Selbstverständlich ist mir klar, daß das großer Mist war. Daß auch hier, wie allg. üblich, die führenden Tiefstriche von "_rl_echoing_p" eine private Variable bezeichnen, wurde mir bestätigt, als ich die Definition von "_rl_echoing_p" in der "rlprivate.h" gefunden habe. Zudem läßt sich aus den "CHANGES" ersehen, warum in der letzten Zeit Änderungen beim "Echoing" durchgeführt wurden. Den veränderten GDB habe ich daher nur testweise verwendet.
</hinweis>
Jetzt zu meiner Folgerung: Meine Version des GDB6 greift dummerweise direkt auf eine Variable von libreadline zu; zu allem Übel existiert diese in der neuen, verbesserten Version nicht mehr.
Falls jemand das Ding bei sich übersetzt bekäme, müßte er gemäß meiner Theorie entweder über eine ältere libreadline (vor 6.0?) oder einen neueren GDB (nach 6.6?) verfügen. Dieser befindet sich aber nicht in meinem Ports-Verzeichnis:
Mein Ports-Verzeichnis sollte eigentlich aktuell sein, gibt das Erwartete aber anscheinend nicht her.
Gruß
Kurama
Vor geschätzt gut einem Jahr hatte ich Schwierigkeiten beim Durchführen von "portupgrade devel/gdb6". Unter meinem System konnte ich das Ding nur mit einem Hack übersetzen und habe mal kurz bei dem zuständigen Maintainer nachgefragt. Nach seiner Aussage lies sich das Problem aber bei ihm nicht reproduzieren, und ich ließ die Sache auf sich beruhen.
Nun hatte ich aber gerade auf einem anderen Rechner dasselbe Problem und wollte mich mal umhören, ob es sich dabei immer nur um Einzelfälle handelt.
Hier eine kurze Beschreibung:
Beim Linken bricht "portupgrade devel/gdb6" mit dieser Fehlermeldung ab:
Code:
libgdb.a(tui-io.o)(.text+0x24d): In function `tui_setup_io':
: undefined reference to `readline_echoing_p'
libgdb.a(tui-io.o)(.text+0x280): In function `tui_setup_io':
: undefined reference to `readline_echoing_p'
libgdb.a(tui-io.o)(.text+0x36c): In function `tui_setup_io':
: undefined reference to `readline_echoing_p'Anscheinend kann der Linker die Variable "readline_echoing_p" nicht finden, die in der Datei "/usr/ports/devel/gdb6/work/gdb-6.6/gdb/tui/tui-io.c" in der Funktion "void tui_setup_io (int mode)" durch "extern int readline_echoing_p" in der Zeile 508 deklariert wurde.
Im Netz habe ich unter http://bugs.gentoo.org/show_bug.cgi?id=259932 den Hinweis gefunden, daß der Fehler unter der Bedingung "sys-libs/readline" >= 6.0 (Linux-Pfad!) auftreten soll.
Beim Untersuchen meiner "libreadline" fiel mir damals folgendes auf:
Code:
$ nm /usr/local/lib/libreadline.so.6 | grep echoing
00031bdc B _rl_echoing_pBei meinem alten Hack hatte ich probeweise in der "tui-io.c" den Namen an diese Variable angepaßt, zwar nicht systematisch getestet, aber es schien ersteinmal zu laufen.
<hinweis>
Bevor mich noch jemand für einen Hirni hält: Selbstverständlich ist mir klar, daß das großer Mist war. Daß auch hier, wie allg. üblich, die führenden Tiefstriche von "_rl_echoing_p" eine private Variable bezeichnen, wurde mir bestätigt, als ich die Definition von "_rl_echoing_p" in der "rlprivate.h" gefunden habe. Zudem läßt sich aus den "CHANGES" ersehen, warum in der letzten Zeit Änderungen beim "Echoing" durchgeführt wurden. Den veränderten GDB habe ich daher nur testweise verwendet.
</hinweis>
Jetzt zu meiner Folgerung: Meine Version des GDB6 greift dummerweise direkt auf eine Variable von libreadline zu; zu allem Übel existiert diese in der neuen, verbesserten Version nicht mehr.
Falls jemand das Ding bei sich übersetzt bekäme, müßte er gemäß meiner Theorie entweder über eine ältere libreadline (vor 6.0?) oder einen neueren GDB (nach 6.6?) verfügen. Dieser befindet sich aber nicht in meinem Ports-Verzeichnis:
Code:
$ ls -dl /usr/ports/devel/gdb*
drwxr-xr-x 3 root wheel 512 Feb 2 2009 /usr/ports/devel/gdb53-act
drwxr-xr-x 4 root wheel 512 Aug 5 09:46 /usr/ports/devel/gdb6
drwxr-xr-x 4 root wheel 512 Aug 5 12:49 /usr/ports/devel/gdb66
drwxr-xr-x 2 root wheel 512 Jan 6 2010 /usr/ports/devel/gdbmods
$ grep PORT /usr/ports/devel/gdb6/Makefile | head -3
PORTNAME= gdb
PORTVERSION= 6.6
PORTREVISION= 2
$ grep PORT /usr/ports/devel/gdb66/Makefile | head -3
PORTNAME= gdb
PORTVERSION= 6.6
PORTREVISION= 2
$ pkg_info | grep readline
readline-6.1 A library [...]
$ uname -a
FreeBSD wilbis 7.3-RELEASE FreeBSD 7.3-RELEASE #4: Wed Apr 21 12:37:17 CEST 2010 root@wilbis:/usr/obj/usr/src/sys/WILBIS_SCENIC_E i386Mein Ports-Verzeichnis sollte eigentlich aktuell sein, gibt das Erwartete aber anscheinend nicht her.
Gruß
Kurama
.