Python enabled gdb on Windows and relocation
Hi, I am currently trying to integrate Python support into my toolchain build (including GDB of course). It is a sysrooted binutils+GCC+GDB+mingw-w64 toolchain. I currently have the basic setup working: I can link gdb with my manually generated import lib to the python dll from the official Windows install. If there is anything I am missing or a very easy solution to the problems decsribed below, please just say so. I am only suggesting what I would like to happen. Now on to the problems I'd like to discuss: 1. gdb.exe won't start without me having set PYTHONPATH manually. I understand the need for this, but as gdb requires Python 2, and users of my toolchain may have installed Python 3 or a 32-bit version python they want to use from the same environment (without changing their own PYTHONPATH), there is no way to run python-enabled gdb. What I suggest is perhaps a Windows only change: a kind of "sysroot"ed gdb+python, so that the python used by gdb is truly built in. I cannot require everyone using my toolchain to install the correct python version for obvious reasons (Windows != Linux in this regard). However way this is tackled, the gdb I want should look relative to it's current (relocatable) directory for Python modules/*;py files in a well-defined directory at build time. That would allow me to distribute gdb in a very clear way: /bin /bin/python27.dll /bin/gdb.exe /lib /lib/python27 /lib/python27/ Currently, this scheme only works if I manually set the PYTHONPATH environment variable to /lib/python27. This global environment variable could conflict with existing Python installations, that may have another bitness (I have 64- and 32-bit toolchains). I think you can see there are problems enough with the current set up. I also read this old discussion: http://comments.gmane.org/gmane.comp.gdb.patches/62811 that might imply that the PYTHONPATH check is something built-in to the python dll. Can anyone shed some light on this? 2. With PYTHONPATH set as a temporary workaround, gdb starts, but spits out a traceback: Traceback (most recent call last): File "", line 35, in File "m:\development\mingw64\share\gdb/python/gdb/__init__.py", line 18, in gdb.command.pretty_printers.register_pretty_printer_commands() File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py", line 368, in register_pretty_printer_commands InfoPrettyPrinter() File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py", line 100, in __init__ gdb.COMMAND_DATA) RuntimeError: Could not find command prefix info. This is a minor problem I think, as "python import time" "python print time.clock()" works as expected. What is wrong? Thanks very much! Ruben PS: I've sent this to both the gdb and python mailing lists, as these issues have a large overlap to both projects. PS2: Please reply-to-all as I do not want daily mails from both mailing lists on every issue brought up there. My apologies. -- http://mail.python.org/mailman/listinfo/python-list
Python enabled gdb on Windows and relocation
(now in plain-text as required by gdb mailing list) Hi, I am currently trying to integrate Python support into my toolchain build (including GDB of course). It is a sysrooted binutils+GCC+GDB+mingw-w64 toolchain. I currently have the basic setup working: I can link gdb with my manually generated import lib to the python dll from the official Windows install. If there is anything I am missing or a very easy solution to the problems decsribed below, please just say so. I am only suggesting what I would like to happen. Now on to the problems I'd like to discuss: 1. gdb.exe won't start without me having set PYTHONPATH manually. I understand the need for this, but as gdb requires Python 2, and users of my toolchain may have installed Python 3 or a 32-bit version python they want to use from the same environment (without changing their own PYTHONPATH), there is no way to run python-enabled gdb. What I suggest is perhaps a Windows only change: a kind of "sysroot"ed gdb+python, so that the python used by gdb is truly built in. I cannot require everyone using my toolchain to install the correct python version for obvious reasons (Windows != Linux in this regard). However way this is tackled, the gdb I want should look relative to it's current (relocatable) directory for Python modules/*;py files in a well-defined directory at build time. That would allow me to distribute gdb in a very clear way: /bin /bin/python27.dll /bin/gdb.exe /lib /lib/python27 /lib/python27/ Currently, this scheme only works if I manually set the PYTHONPATH environment variable to /lib/python27. This global environment variable could conflict with existing Python installations, that may have another bitness (I have 64- and 32-bit toolchains). I think you can see there are problems enough with the current set up. I also read this old discussion: http://comments.gmane.org/gmane.comp.gdb.patches/62811 that might imply that the PYTHONPATH check is something built-in to the python dll. Can anyone shed some light on this? 2. With PYTHONPATH set as a temporary workaround, gdb starts, but spits out a traceback: Traceback (most recent call last): File "", line 35, in File "m:\development\mingw64\share\gdb/python/gdb/__init__.py", line 18, in gdb.command.pretty_printers.register_pretty_printer_commands() File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py", line 368, in register_pretty_printer_commands InfoPrettyPrinter() File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py", line 100, in __init__ gdb.COMMAND_DATA) RuntimeError: Could not find command prefix info. This is a minor problem I think, as "python import time" "python print time.clock()" works as expected. What is wrong? Thanks very much! Ruben PS: I've sent this to both the gdb and python mailing lists, as these issues have a large overlap to both projects. PS2: Please reply-to-all as I do not want daily mails from both mailing lists on every issue brought up there. My apologies. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python enabled gdb on Windows and relocation
2011/5/14 Doug Evans : > On Thu, May 12, 2011 at 9:19 AM, Ruben Van Boxem > wrote: >> (now in plain-text as required by gdb mailing list) >> >> Hi, >> >> I am currently trying to integrate Python support into my toolchain >> build (including GDB of course). It is a sysrooted >> binutils+GCC+GDB+mingw-w64 toolchain. >> >> I currently have the basic setup working: I can link gdb with my >> manually generated import lib to the python dll from the official >> Windows install. If there is anything I am missing or a very easy >> solution to the problems decsribed below, please just say so. I am >> only suggesting what I would like to happen. >> >> Now on to the problems I'd like to discuss: >> >> 1. gdb.exe won't start without me having set PYTHONPATH manually. > > In a properly configured/built gdb on linux this isn't necessary, even > if python is installed in some random place. > I'm not sure about windows though. > Did you specify --with-python when you configured gdb, and if so did > you specify a value? > e.g., --with-python=SOME_VALUE I was cross-compiling a mingw toolchain+gdb from Linux, so I used --with-python without a value (because gdb configure tries to find the Python executabe), and I added -I"/path/to/python/includes" to CFLAGS and -L"/path/to/pythondll/importlib" to LDFLAGS, which built as it should. This is hacky though, and gdb configure should provide --with-python-libs and --with-python-include to make it more streamlined with any other build prerequisite (like gmp/mpfr/mpc/cloog/ppl in GCC for example). > >> I understand the need for this, but as gdb requires Python 2, and users >> of my toolchain may have installed Python 3 or a 32-bit version python >> they want to use from the same environment (without changing their own >> PYTHONPATH), there is no way to run python-enabled gdb. >> [...] > > Yeah. > There is a proposal to add GDB_PYTHONPATH (or some such IIRC) and have > gdb use that instead of PYTHONPATH if it exists, but there's been > resistance to it. > I think(!) what would happen is that gdb would set $PYTHONPATH to the > value of $GDB_PYTHONPATH. > [Inferiors started by gdb should still get the original value of > PYTHONPATH though.] That way would be almost ideal, but a hardcoded *relative* path to the python scripts (that is standardized within gdb) wouldn't hurt. An extra environment variable would require a lot of explaining for Windows, and is not "plug-and-play", like the rest of a sysrooted toolchain is supposed to be like. I think this should work on all setups: 1. Check hardcoded path; my suggestion would be "/../lib/python27" 2. If this fails to find the necessary files/scripts, find it like you described above in Linux, without PYTHONPATH set. 3. Check PYTHONPATH. I would think only number one would change, and perhaps be only enabled with a special configure option. Nothing else would have to change, and Windows users would rejoice :) Again, this is only my suggestion, if there are problems with it in way I haven't thought of, please say so, and we can come up with another solution. > >> 2. With PYTHONPATH set as a temporary workaround, gdb starts, but >> spits out a traceback: >> Traceback (most recent call last): >> File "", line 35, in >> File "m:\development\mingw64\share\gdb/python/gdb/__init__.py", line >> 18, in >> gdb.command.pretty_printers.register_pretty_printer_commands() >> File >> "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py", >> line 368, in register_pretty_printer_commands >> InfoPrettyPrinter() >> File >> "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py", >> line 100, in __init__ >> gdb.COMMAND_DATA) >> RuntimeError: Could not find command prefix info. >> >> This is a minor problem I think, as "python import time" "python print >> time.clock()" works as expected. What is wrong? > > I'm not sure. > The error message is complaining that the "info" command prefix doesn't exist. > I don't see how that can happen as python is initialized long after > the info command is created. > Thanks for the prompt response. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python enabled gdb on Windows and relocation
2011/5/14 Eli Zaretskii : >> Date: Sat, 14 May 2011 11:09:13 +0200 >> From: Ruben Van Boxem >> Cc: g...@sourceware.org, python-list@python.org >> >> 1. Check hardcoded path; my suggestion would be "> executable>/../lib/python27" >> 2. If this fails to find the necessary files/scripts, find it like you >> described above in Linux, without PYTHONPATH set. >> 3. Check PYTHONPATH. >> >> I would think only number one would change, and perhaps be only >> enabled with a special configure option. Nothing else would have to >> change, and Windows users would rejoice :) > > The problem, I think, is that it's not so easy on Unix to get the > place where the GDB executable leaves. There isn't a system call to > do that (similar to what Windows gives you). > > So I think on Posix platforms, number 2 would be used most of the > time. > I understand. So better/feasible would be: Windows: Check /../lib/python27 or any configure-time specified relative path to gdb executable? If that fails, revert to current behavoir. POSIX (so pretty much everythin else): Keep current behavior. Which would come down to a configure option+ a small block of #if _WIN32 code in the Python part of the code. Thanks, Ruben -- http://mail.python.org/mailman/listinfo/python-list
Re: Python enabled gdb on Windows and relocation
2011/5/14 Doug Evans : > On Sat, May 14, 2011 at 2:09 AM, Ruben Van Boxem > wrote: >> 2011/5/14 Doug Evans : >>> On Thu, May 12, 2011 at 9:19 AM, Ruben Van Boxem >>> wrote: >>>> (now in plain-text as required by gdb mailing list) >>>> >>>> Hi, >>>> >>>> I am currently trying to integrate Python support into my toolchain >>>> build (including GDB of course). It is a sysrooted >>>> binutils+GCC+GDB+mingw-w64 toolchain. >>>> >>>> I currently have the basic setup working: I can link gdb with my >>>> manually generated import lib to the python dll from the official >>>> Windows install. If there is anything I am missing or a very easy >>>> solution to the problems decsribed below, please just say so. I am >>>> only suggesting what I would like to happen. >>>> >>>> Now on to the problems I'd like to discuss: >>>> >>>> 1. gdb.exe won't start without me having set PYTHONPATH manually. >>> >>> In a properly configured/built gdb on linux this isn't necessary, even >>> if python is installed in some random place. >>> I'm not sure about windows though. >>> Did you specify --with-python when you configured gdb, and if so did >>> you specify a value? >>> e.g., --with-python=SOME_VALUE >> >> I was cross-compiling a mingw toolchain+gdb from Linux, so I used >> --with-python without a value (because gdb configure tries to find the >> Python executabe), and I added -I"/path/to/python/includes" to CFLAGS >> and -L"/path/to/pythondll/importlib" to LDFLAGS, which built as it >> should. This is hacky though, and gdb configure should provide >> --with-python-libs and --with-python-include to make it more >> streamlined with any other build prerequisite (like >> gmp/mpfr/mpc/cloog/ppl in GCC for example). > > Ah. > Cross-compiling gdb with python is in need of improvement. > Alas python hasn't been designed with cross-compilation in mind (e.g. > build on linux, run on windows). > AIUI, the way to get the parameters required for compiling with > libpython is to get them from python's "distutils": kinda hard to do > in a cross-compile. Done correctly there's no need to run python. > > I haven't done anything more to support python in gdb's configure.ac > because it's not clear to me what the right thing to do is: distutils > provides more than just --libs and --includes (btw, we don't use > --libs though, we use --ldflags which includes all of: the directory > in which to find libpython, the -l for libpython, and the -l's for all > the other libraries python needs). [Which isn't to say that someone > else isn't free to tackle this.] > > In the meantime, what I've been doing is a hack: write a script that > responds to: > --includes > --ldflags > --exec-prefix > and pass that as --with-python. > > E.g. > bash$ cat $HOME/my-python-for-config > #! /bin/sh > > if [ $# -ne 2 ] > then > echo "Bad # args. Blech!" >&2 > exit 1 > fi > > # The first argument is the path to python-config.py, ignore it. > > case "$2" in > --includes) echo "-I/usr/include/python2.6 -I/usr/include/python2.6" ;; > --ldflags) echo "-L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm > -lpython2.6" ;; > --exec-prefix) echo "/usr" ;; > *) echo "Bad arg $2. Blech!" >&2 ; exit 1 ;; > esac > > exit 0 > bash$ ./configure --with-python=$HOME/my-python-for-config [...] > [...] > > > Note that --exec-prefix is the runtime location of python. > GCC uses this to tell libpython where to find its support files. > [grep for Py_SetProgramName in gdb/python/python.c] OK, I tried your script in a couple of variations. It gets rid of the traceback I had before, but still doesn't help the PYTHONPATH problem. My directory structure is as follows (this is not in root, "/" is just my main build directory, there are several levels below it): /gdb <-- gdb build dir /gdb/gdb <-- where the python configuration is done /python <-- temporary install dir for python files for build, extracted from the official Windows installer, also location of libpython2.7.a import library /python/include/python27 <-- python headers, found by gdb in both cases /mingw64 <-- toolchain sysroot prefix /mingw64/bin <-- install location of gdb and python27.dll /mingw64/lib/python27 <-- install location of all python scripts First variant: --includes) echo "-I../../python
Re: Python enabled gdb on Windows and relocation
2011/5/15 Ruben Van Boxem : > 2011/5/14 Doug Evans : >> On Sat, May 14, 2011 at 2:09 AM, Ruben Van Boxem >> wrote: >>> 2011/5/14 Doug Evans : >>>> On Thu, May 12, 2011 at 9:19 AM, Ruben Van Boxem >>>> wrote: >>>>> (now in plain-text as required by gdb mailing list) >>>>> >>>>> Hi, >>>>> >>>>> I am currently trying to integrate Python support into my toolchain >>>>> build (including GDB of course). It is a sysrooted >>>>> binutils+GCC+GDB+mingw-w64 toolchain. >>>>> >>>>> I currently have the basic setup working: I can link gdb with my >>>>> manually generated import lib to the python dll from the official >>>>> Windows install. If there is anything I am missing or a very easy >>>>> solution to the problems decsribed below, please just say so. I am >>>>> only suggesting what I would like to happen. >>>>> >>>>> Now on to the problems I'd like to discuss: >>>>> >>>>> 1. gdb.exe won't start without me having set PYTHONPATH manually. >>>> >>>> In a properly configured/built gdb on linux this isn't necessary, even >>>> if python is installed in some random place. >>>> I'm not sure about windows though. >>>> Did you specify --with-python when you configured gdb, and if so did >>>> you specify a value? >>>> e.g., --with-python=SOME_VALUE >>> >>> I was cross-compiling a mingw toolchain+gdb from Linux, so I used >>> --with-python without a value (because gdb configure tries to find the >>> Python executabe), and I added -I"/path/to/python/includes" to CFLAGS >>> and -L"/path/to/pythondll/importlib" to LDFLAGS, which built as it >>> should. This is hacky though, and gdb configure should provide >>> --with-python-libs and --with-python-include to make it more >>> streamlined with any other build prerequisite (like >>> gmp/mpfr/mpc/cloog/ppl in GCC for example). >> >> Ah. >> Cross-compiling gdb with python is in need of improvement. >> Alas python hasn't been designed with cross-compilation in mind (e.g. >> build on linux, run on windows). >> AIUI, the way to get the parameters required for compiling with >> libpython is to get them from python's "distutils": kinda hard to do >> in a cross-compile. Done correctly there's no need to run python. >> >> I haven't done anything more to support python in gdb's configure.ac >> because it's not clear to me what the right thing to do is: distutils >> provides more than just --libs and --includes (btw, we don't use >> --libs though, we use --ldflags which includes all of: the directory >> in which to find libpython, the -l for libpython, and the -l's for all >> the other libraries python needs). [Which isn't to say that someone >> else isn't free to tackle this.] >> >> In the meantime, what I've been doing is a hack: write a script that >> responds to: >> --includes >> --ldflags >> --exec-prefix >> and pass that as --with-python. >> >> E.g. >> bash$ cat $HOME/my-python-for-config >> #! /bin/sh >> >> if [ $# -ne 2 ] >> then >> echo "Bad # args. Blech!" >&2 >> exit 1 >> fi >> >> # The first argument is the path to python-config.py, ignore it. >> >> case "$2" in >> --includes) echo "-I/usr/include/python2.6 -I/usr/include/python2.6" ;; >> --ldflags) echo "-L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm >> -lpython2.6" ;; >> --exec-prefix) echo "/usr" ;; >> *) echo "Bad arg $2. Blech!" >&2 ; exit 1 ;; >> esac >> >> exit 0 >> bash$ ./configure --with-python=$HOME/my-python-for-config [...] >> [...] >> >> >> Note that --exec-prefix is the runtime location of python. >> GCC uses this to tell libpython where to find its support files. >> [grep for Py_SetProgramName in gdb/python/python.c] > > OK, I tried your script in a couple of variations. It gets rid of the > traceback I had before, but still doesn't help the PYTHONPATH problem. > My directory structure is as follows (this is not in root, "/" is just > my main build directory, there are several levels below it): > > /gdb <-- gdb build dir > /gdb/gdb <-- where the python configuration is done > /python <-- temporary i
Re: Python enabled gdb on Windows and relocation
2011/5/15 Ruben Van Boxem : > 2011/5/15 Ruben Van Boxem : >> 2011/5/14 Doug Evans : >>> On Sat, May 14, 2011 at 2:09 AM, Ruben Van Boxem >>> wrote: >>>> 2011/5/14 Doug Evans : >>>>> On Thu, May 12, 2011 at 9:19 AM, Ruben Van Boxem >>>>> wrote: >>>>>> (now in plain-text as required by gdb mailing list) >>>>>> >>>>>> Hi, >>>>>> >>>>>> I am currently trying to integrate Python support into my toolchain >>>>>> build (including GDB of course). It is a sysrooted >>>>>> binutils+GCC+GDB+mingw-w64 toolchain. >>>>>> >>>>>> I currently have the basic setup working: I can link gdb with my >>>>>> manually generated import lib to the python dll from the official >>>>>> Windows install. If there is anything I am missing or a very easy >>>>>> solution to the problems decsribed below, please just say so. I am >>>>>> only suggesting what I would like to happen. >>>>>> >>>>>> Now on to the problems I'd like to discuss: >>>>>> >>>>>> 1. gdb.exe won't start without me having set PYTHONPATH manually. >>>>> >>>>> In a properly configured/built gdb on linux this isn't necessary, even >>>>> if python is installed in some random place. >>>>> I'm not sure about windows though. >>>>> Did you specify --with-python when you configured gdb, and if so did >>>>> you specify a value? >>>>> e.g., --with-python=SOME_VALUE >>>> >>>> I was cross-compiling a mingw toolchain+gdb from Linux, so I used >>>> --with-python without a value (because gdb configure tries to find the >>>> Python executabe), and I added -I"/path/to/python/includes" to CFLAGS >>>> and -L"/path/to/pythondll/importlib" to LDFLAGS, which built as it >>>> should. This is hacky though, and gdb configure should provide >>>> --with-python-libs and --with-python-include to make it more >>>> streamlined with any other build prerequisite (like >>>> gmp/mpfr/mpc/cloog/ppl in GCC for example). >>> >>> Ah. >>> Cross-compiling gdb with python is in need of improvement. >>> Alas python hasn't been designed with cross-compilation in mind (e.g. >>> build on linux, run on windows). >>> AIUI, the way to get the parameters required for compiling with >>> libpython is to get them from python's "distutils": kinda hard to do >>> in a cross-compile. Done correctly there's no need to run python. >>> >>> I haven't done anything more to support python in gdb's configure.ac >>> because it's not clear to me what the right thing to do is: distutils >>> provides more than just --libs and --includes (btw, we don't use >>> --libs though, we use --ldflags which includes all of: the directory >>> in which to find libpython, the -l for libpython, and the -l's for all >>> the other libraries python needs). [Which isn't to say that someone >>> else isn't free to tackle this.] >>> >>> In the meantime, what I've been doing is a hack: write a script that >>> responds to: >>> --includes >>> --ldflags >>> --exec-prefix >>> and pass that as --with-python. >>> >>> E.g. >>> bash$ cat $HOME/my-python-for-config >>> #! /bin/sh >>> >>> if [ $# -ne 2 ] >>> then >>> echo "Bad # args. Blech!" >&2 >>> exit 1 >>> fi >>> >>> # The first argument is the path to python-config.py, ignore it. >>> >>> case "$2" in >>> --includes) echo "-I/usr/include/python2.6 -I/usr/include/python2.6" ;; >>> --ldflags) echo "-L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm >>> -lpython2.6" ;; >>> --exec-prefix) echo "/usr" ;; >>> *) echo "Bad arg $2. Blech!" >&2 ; exit 1 ;; >>> esac >>> >>> exit 0 >>> bash$ ./configure --with-python=$HOME/my-python-for-config [...] >>> [...] >>> >>> >>> Note that --exec-prefix is the runtime location of python. >>> GCC uses this to tell libpython where to find its support files. >>> [grep for Py_SetProgramName in gdb/python/python.c] >> >> OK, I tried your
Re: Python enabled gdb on Windows and relocation
2011/5/15 Ruben Van Boxem : > 2011/5/15 Ruben Van Boxem : >> 2011/5/15 Ruben Van Boxem : >>> 2011/5/14 Doug Evans : >>>> On Sat, May 14, 2011 at 2:09 AM, Ruben Van Boxem >>>> wrote: >>>>> 2011/5/14 Doug Evans : >>>>>> On Thu, May 12, 2011 at 9:19 AM, Ruben Van Boxem >>>>>> wrote: >>>>>>> (now in plain-text as required by gdb mailing list) >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am currently trying to integrate Python support into my toolchain >>>>>>> build (including GDB of course). It is a sysrooted >>>>>>> binutils+GCC+GDB+mingw-w64 toolchain. >>>>>>> >>>>>>> I currently have the basic setup working: I can link gdb with my >>>>>>> manually generated import lib to the python dll from the official >>>>>>> Windows install. If there is anything I am missing or a very easy >>>>>>> solution to the problems decsribed below, please just say so. I am >>>>>>> only suggesting what I would like to happen. >>>>>>> >>>>>>> Now on to the problems I'd like to discuss: >>>>>>> >>>>>>> 1. gdb.exe won't start without me having set PYTHONPATH manually. >>>>>> >>>>>> In a properly configured/built gdb on linux this isn't necessary, even >>>>>> if python is installed in some random place. >>>>>> I'm not sure about windows though. >>>>>> Did you specify --with-python when you configured gdb, and if so did >>>>>> you specify a value? >>>>>> e.g., --with-python=SOME_VALUE >>>>> >>>>> I was cross-compiling a mingw toolchain+gdb from Linux, so I used >>>>> --with-python without a value (because gdb configure tries to find the >>>>> Python executabe), and I added -I"/path/to/python/includes" to CFLAGS >>>>> and -L"/path/to/pythondll/importlib" to LDFLAGS, which built as it >>>>> should. This is hacky though, and gdb configure should provide >>>>> --with-python-libs and --with-python-include to make it more >>>>> streamlined with any other build prerequisite (like >>>>> gmp/mpfr/mpc/cloog/ppl in GCC for example). >>>> >>>> Ah. >>>> Cross-compiling gdb with python is in need of improvement. >>>> Alas python hasn't been designed with cross-compilation in mind (e.g. >>>> build on linux, run on windows). >>>> AIUI, the way to get the parameters required for compiling with >>>> libpython is to get them from python's "distutils": kinda hard to do >>>> in a cross-compile. Done correctly there's no need to run python. >>>> >>>> I haven't done anything more to support python in gdb's configure.ac >>>> because it's not clear to me what the right thing to do is: distutils >>>> provides more than just --libs and --includes (btw, we don't use >>>> --libs though, we use --ldflags which includes all of: the directory >>>> in which to find libpython, the -l for libpython, and the -l's for all >>>> the other libraries python needs). [Which isn't to say that someone >>>> else isn't free to tackle this.] >>>> >>>> In the meantime, what I've been doing is a hack: write a script that >>>> responds to: >>>> --includes >>>> --ldflags >>>> --exec-prefix >>>> and pass that as --with-python. >>>> >>>> E.g. >>>> bash$ cat $HOME/my-python-for-config >>>> #! /bin/sh >>>> >>>> if [ $# -ne 2 ] >>>> then >>>> echo "Bad # args. Blech!" >&2 >>>> exit 1 >>>> fi >>>> >>>> # The first argument is the path to python-config.py, ignore it. >>>> >>>> case "$2" in >>>> --includes) echo "-I/usr/include/python2.6 -I/usr/include/python2.6" ;; >>>> --ldflags) echo "-L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm >>>> -lpython2.6" ;; >>>> --exec-prefix) echo "/usr" ;; >>>> *) echo "Bad arg $2. Blech!" >&2 ; exit 1 ;; >>>> esac >>>> >>>> exit 0 >>
