Joel Brobecker brobec...@gnat.com added the comment:
More update on this patch: It's incomplete, and possibly wrong, unfortunately.
The issue that someone else noticed is that it does not handle the case when
Python was configured with --libdir=...; and I think that the default lib dir
on
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo, tarek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7352
___
___
Python-bugs-list
Terry J. Reedy tjre...@udel.edu added the comment:
I am not sure that such a change to python-config.in could go into a bugfix
release as it might need more testing on a variety of systems than bugfix
releases tend to get. Does (in your opinion) 3.1/2 need the same change?
Martin, who should
Joel Brobecker brobec...@gnat.com added the comment:
I agree that more testing in head would be useful before possibly considering
inclusion in one of the bug-fix releases. Given that this only affects binaries
installed at a different location than the configure prefix, this seems hardly
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 -Lpath returned by python-config --ldflags refered to the prefix used
at
Changes by François Mauger mau...@lpccaen.in2p3.fr:
--
components: Installation
nosy: mauger
severity: normal
status: open
title: python2.6-config --ldflags out of /usr and missing -Linstall_lib_dir
type: feature request
versions: Python 2.6
___
New submission from François Mauger mau...@lpccaen.in2p3.fr:
Hi Python!
I installed python2.6 from official source tarball under Scientific
Linux 5.2. I use the python2.6-config utility through makefiles to link
against lipython2.6.so. The installation prefix is NOT /usr nor some
standard
