Hi,
maybe you know, just in case not...
You allow use of bespoke python build for the most part. There is an
issue in the linking though - I had to make the following change so that
gdb was linked with my python rather than the system one. I suppose
that you should set some sort of PYTHONLIBS variable that contains the
path to the relevant libs (somewhat like you do for INTERNAL_CPP_FLAGS).
CLIBS = $(SIM) $(READLINE) $(OPCODES) $(BFD) $(INTL) $(LIBIBERTY)
$(LIBDECNUMBER) \
$(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) -ldl -lncurses -lz -lm
-lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic \
$(LIBEXPAT) \
$(LIBIBERTY) $(WIN32LIBS) $(LIBGNU)
CLIBS = $(SIM) $(READLINE) $(OPCODES) $(BFD) $(INTL) $(LIBIBERTY)
$(LIBDECNUMBER) \
$(XM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) -ldl -lncurses -lz -lm
-lpthread -ldl -lutil -lm -L$(MY_PYTHON)/lib -lpython2.7 -Xlinker
-export-dynamic \
$(LIBEXPAT) \
$(LIBIBERTY) $(WIN32LIBS) $(LIBGNU)
Incidentally, the reason why I was compiling was this:
$ gdb `which python` core.23394
gdb: symbol lookup error: gdb: undefined symbol:
PyUnicodeUCS4_FromEncodedObject
confusion with unicode...
Regards,
Paul.
_______________________________________________
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
