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.