WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Building gdb with python 2.7 support  (Read 4993 times)

Offline Zill

  • Newbie
  • *
  • Posts: 25
Building gdb with python 2.7 support
« on: June 26, 2015, 07:47:26 AM »
As the title says I am trying to build gdb with python 2.7 support.  I am using Tiny Core 5.4 (32bit) as a virtualbox guest.  I downloaded gdb 7.5.1 as that is the current version in the repo.  I checked the dependencies listed and made sure to install those from the repo.  I decompressed the gdb source, ran "./configure --prefix=/usr/local --with-python --with-ncurses" and it runs fine.  I then run make and it throws the following errors:

Code: [Select]
gcc -g -O2   -I. -I. -I./common -I./config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber  -I./gnulib/import -Ibuild-gnulib/import   -DTUI=1  -I/usr/local/include/python2.7 -I/usr/local/include/python2.7 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement  -c -o tui-command.o -MT tui-command.o -MMD -MP -MF .deps/tui-command.Tpo ./tui/tui-command.c
In file included from ./tui/tui-command.c:25:0:
./tui/tui-data.h:38:3: error: unknown type name 'WINDOW'
In file included from ./tui/tui-command.c:26:0:
./tui/tui-win.h:40:1: error: unknown type name 'chtype'
./tui/tui-win.h:41:1: error: unknown type name 'chtype'
./tui/tui-win.h:42:1: error: unknown type name 'chtype'
./tui/tui-win.h:43:1: error: unknown type name 'chtype'
./tui/tui-win.h:44:1: error: unknown type name 'chtype'
./tui/tui-win.h:45:1: error: unknown type name 'chtype'
./tui/tui-command.c: In function 'tui_dispatch_ctrl_char':
./tui/tui-command.c:79:15: error: unknown type name 'WINDOW'
./tui/tui-command.c:84:5: warning: implicit declaration of function 'wgetch' [-Wimplicit-function-declaration]
./tui/tui-command.c:85:21: error: 'ERR' undeclared (first use in this function)
./tui/tui-command.c:85:21: note: each undeclared identifier is reported only once for each function it appears in
./tui/tui-command.c:92:17: error: 'KEY_PPAGE' undeclared (first use in this function)
./tui/tui-command.c:94:17: error: 'KEY_NPAGE' undeclared (first use in this function)
./tui/tui-command.c:112:7: error: 'KEY_DOWN' undeclared (first use in this function)
./tui/tui-command.c:113:7: error: 'KEY_SF' undeclared (first use in this function)
./tui/tui-command.c:116:7: error: 'KEY_UP' undeclared (first use in this function)
./tui/tui-command.c:117:7: error: 'KEY_SR' undeclared (first use in this function)
./tui/tui-command.c:120:7: error: 'KEY_RIGHT' undeclared (first use in this function)
./tui/tui-command.c:123:7: error: 'KEY_LEFT' undeclared (first use in this function)
make[2]: *** [tui-command.o] Error 1
make[2]: Leaving directory `/home/tc/build/gdb-7.5.1/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/home/tc/build/gdb-7.5.1'
make: *** [all] Error 2
tc@box:~/build/gdb-7.5.1$

In my research I found the following link https://github.com/hashdist/hashstack/issues/710, which said I needed to export some flags.  Some more looking around and I found http://wiki.tinycorelinux.net/wiki:creating_extensions which let me know what to set those flags to:
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export LDFLAGS="-Wl,-O1"
but I still get the same errors.  I'm going to keep looking, but any help would be greatly appreciated.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14819
Re: Building gdb with python 2.7 support
« Reply #1 on: June 26, 2015, 09:04:18 AM »
did you load python-dev and ncurses-dev?

Offline Zill

  • Newbie
  • *
  • Posts: 25
Re: Building gdb with python 2.7 support
« Reply #2 on: June 26, 2015, 09:36:50 AM »
Juanito, thanks for the quick response.  Both of those were loaded before hand.  I have made a work around for the problem.  It turns out that CPPFLAGS and CXXFLAGS are not the same thing (silly me).  The failure was caused by not defining HAVE_NCURSES_H and HAVE_TERM_H defined.  This was located in gdb_curses.h.  I did
Code: [Select]
export CPPFLAGS="-DHAVE_NCURSES_FILE -DHAVE_TERM_FILE"
but that still didn't work.  So I went into gdb_curses.h and commented out the #ifelsedefined statements and it works.  But this has brought me to my next problem

Code: [Select]
gcc -g -O2      \
        -o gdb gdb.o i386-tdep.o i386-linux-tdep.o glibc-tdep.o i387-tdep.o solib-svr4.o symfile-mem.o linux-tdep.o linux-record.o ser-base.o ser-unix.o ser-pipe.o ser-tcp.o inf-ptrace.o fork-child.o i386-nat.o i386-linux-nat.o proc-service.o linux-thread-db.o linux-nat.o linux-osdata.o linux-fork.o linux-procfs.o linux-ptrace.o remote.o dcache.o tracepoint.o ax-general.o ax-gdb.o remote-fileio.o  cli-dump.o cli-decode.o cli-script.o cli-cmds.o cli-setshow.o cli-logging.o cli-interp.o cli-utils.o mi-out.o mi-console.o mi-cmds.o mi-cmd-env.o mi-cmd-var.o mi-cmd-break.o mi-cmd-stack.o mi-cmd-file.o mi-cmd-disas.o mi-symbol-cmds.o mi-cmd-target.o mi-cmd-info.o mi-interp.o mi-main.o mi-parse.o mi-getopt.o tui-command.o tui-data.o tui-disasm.o tui-file.o tui-hooks.o tui-interp.o tui-io.o tui-layout.o tui-out.o tui-regs.o tui-source.o tui-stack.o tui-win.o tui-windata.o tui-wingeneral.o tui-winsource.o tui.o python.o py-auto-load.o py-block.o py-bpevent.o py-breakpoint.o py-cmd.o py-continueevent.o py-event.o py-evtregistry.o py-evts.o py-exitedevent.o py-finishbreakpoint.o py-frame.o py-function.o py-inferior.o py-infthread.o py-lazy-string.o py-newobjfileevent.o py-objfile.o py-param.o py-prettyprint.o py-progspace.o py-signalevent.o py-stopevent.o py-symbol.o py-symtab.o py-threadevent.o py-type.o py-utils.o py-value.o elfread.o stap-probe.o posix-hdep.o c-exp.o cp-name-parser.o objc-exp.o ada-exp.o jv-exp.o f-exp.o go-exp.o m2-exp.o p-exp.o version.o annotate.o addrmap.o auto-load.o auxv.o agent.o bfd-target.o blockframe.o breakpoint.o findvar.o regcache.o cleanups.o charset.o continuations.o corelow.o disasm.o dummy-frame.o dfp.o source.o value.o eval.o valops.o valarith.o valprint.o printcmd.o block.o symtab.o psymtab.o symfile.o symmisc.o linespec.o dictionary.o infcall.o infcmd.o infrun.o expprint.o environ.o stack.o thread.o exceptions.o filesystem.o inf-child.o interps.o main.o macrotab.o macrocmd.o macroexp.o macroscope.o mi-common.o event-loop.o event-top.o inf-loop.o completer.o gdbarch.o arch-utils.o gdbtypes.o osabi.o copying.o memattr.o mem-break.o target.o parse.o language.o buildsym.o findcmd.o std-regs.o signals.o exec.o reverse.o bcache.o objfiles.o observer.o minsyms.o maint.o demangle.o dbxread.o coffread.o coff-pe-read.o dwarf2read.o mipsread.o stabsread.o corefile.o dwarf2expr.o dwarf2loc.o dwarf2-frame.o dwarf2-frame-tailcall.o ada-lang.o c-lang.o d-lang.o f-lang.o objc-lang.o ada-tasks.o ada-varobj.o ui-out.o cli-out.o varobj.o vec.o go-lang.o go-valprint.o go-typeprint.o jv-lang.o jv-valprint.o jv-typeprint.o m2-lang.o opencl-lang.o p-lang.o p-typeprint.o p-valprint.o sentinel-frame.o complaints.o typeprint.o ada-typeprint.o c-typeprint.o f-typeprint.o m2-typeprint.o ada-valprint.o c-valprint.o cp-valprint.o d-valprint.o f-valprint.o m2-valprint.o serial.o mdebugread.o top.o utils.o ui-file.o user-regs.o frame.o frame-unwind.o doublest.o frame-base.o inline-frame.o gnu-v2-abi.o gnu-v3-abi.o cp-abi.o cp-support.o cp-namespace.o reggroups.o regset.o trad-frame.o tramp-frame.o solib.o solib-target.o prologue-value.o memory-map.o memrange.o xml-support.o xml-syscall.o xml-utils.o target-descriptions.o target-memory.o xml-tdesc.o xml-builtin.o inferior.o osdata.o gdb_usleep.o record.o gcore.o jit.o progspace.o skip.o probe.o common-utils.o buffer.o ptid.o gdb-dlfcn.o common-agent.o format.o inflow.o    init.o \
           ../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a    -ldl -lncurses -lz -lm    -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic /usr/local/lib/libexpat.so -Wl,-rpath -Wl,/usr/local/lib ../libiberty/libiberty.a  build-gnulib/import/libgnu.a -ldl -rdynamic
/usr/local/bin/ld: tui.o: undefined reference to symbol 'def_shell_mode'
/usr/local/bin/ld: note: 'def_shell_mode' is defined in DSO /usr/local/lib/libtinfo.so.5 so try adding it to the linker command line
/usr/local/lib/libtinfo.so.5: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: *** [gdb] Error 1

Once again any help is greatly appreciated.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14819
Re: Building gdb with python 2.7 support
« Reply #3 on: June 26, 2015, 11:58:57 AM »
This worked for me with corepure64 5.x:

http://tinycorelinux.net/5.x/x86_64/tcz/src/gdb/compile_gdb

..you should just need to substitute "-march=i486 -mtune=i686" for "-mtune=generic".

Offline Zill

  • Newbie
  • *
  • Posts: 25
Re: Building gdb with python 2.7 support
« Reply #4 on: June 26, 2015, 01:49:39 PM »
I figured it out, but I'm feeling pretty dumb right now.  I was doing my export commands in a second terminal, causing the first terminal doing the building to not be able to see them.  Once I figured that out, I still ran into a problem with the instructions at http://wiki.tinycorelinux.net/wiki:creating_extensions.  At first I did:
Code: [Select]
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CPPFLAGS="-DHAVE_NCURSES_H -DHAVE_TERM_H"
export LDFLAGS="-ltinfo -W1, -O1"
So after I entered these I started the configure, only to have it halt saying the C compiler did not have permission to create executables.  After looking at the settings Juanito used I noticed that he did not use -W1.  I removed that from my export and everything worked just fine.  I don't know why the -W1 caused the configuration to stop, but I now have it working. 

Thanks a bunch Juanito.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11634
Re: Building gdb with python 2.7 support
« Reply #5 on: June 26, 2015, 03:26:22 PM »
Hi Zill
That should be  wl  as in lower case L, not a 1 as in one.

Offline Zill

  • Newbie
  • *
  • Posts: 25
Re: Building gdb with python 2.7 support
« Reply #6 on: June 30, 2015, 11:32:22 AM »
Rich, Thanks for pointing out why that was failing.