Joel Brobecker <brobec...@gnat.com> added the comment: GDB can suffer from the same sort of problem. In my case, I picked up a Python binary tarball built on a different machine (without --enable-shared), and the path in -L<path> returned by python-config --ldflags refered to the prefix used at configure time. But, by comparison, --cflags returns the correct include path.
To give more context: GDB can be linked against libpython to add python scripting support in GDB. To determine how to compile&link Python in GDB, we have a copy of python-config in GDB, and do "python /path/to/python-config --cflags/ldflags. Because it is often convenient to pick up a binary install, and because this install is not always at the same location as the prefix used at configure time, python-config --ldflags returns a -L<path> with a path that is irrelevant in our case. The attached patch fixes this issue. The patch also fixes the issue originally reported: I think that python-config --ldflags should also print -L<prefix>/lib in the case where python was configured with --enable-shared. This is necessary when prefix is not a standard location. This was tested with Python 2.5, 2.6, and 2.7, static and shared, by calling the script with --ldflags, and by verifying the output. ---------- keywords: +patch nosy: +brobecke Added file: http://bugs.python.org/file17910/python-config.diff _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7352> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
