The PYTHON_LIBS change (asking python itself for its build configuration) is excellent. Assuming that the first parameter in that is the location of the lib (and that there are no embedded spaces in it!) is fragile. And I think that gives you the -L/path flag not just the /path location as the previous would? I'm not sure how PYTHON_LIB_LOC gets used, but there are many python-library packages out there, there's gotta be a standard way to introspect that piece of data too (or work around actually needing it explicitly).

Aha.  In MacPorts, python -c "import sys; print sys.exec_prefix" gives me:
/opt/local/Library/Frameworks/Python.framework/Versions/2.6

but "libpython2.6.dylib" is in /opt/local/lib.  This must be one of the many fragile aspects of MacPorts' strategy for installing multiple Python versions.

Any suggestions?

Maybe this should be reported to MacPorts instead.

I don't know anything about MacPorts's games there, but there's nothing intrinsically wrong with putting python's shared libs in any wacky place on a system, as long as the way python is documented to publish its lib location is correct for that location. It's as much a bug to assume the lib is in $py_prefix/lib as it is to assume it is in /some/main/prefix/lib as it is to assume it's in $py_prefix/lib/python$PYTHON_VERSION/config.

PYTHON_LIB_LOC needs to be just the pathname though (I assume /opt/local/lib for you) not the linker flag that --ldflags gives (I assume -L/opt/local/lib for you). Doesn't matter though...the interal use of PY_LIB_LOC is hardcoded in a linux-centric manner.

See Bug #616592 for a more complex problem about how PYTHON_LIB_LOC is handled.

I poked around and found that I have Python shared libraries in 

/opt/local/lib

e.g.

/opt/local/lib/libpython2.6.dylib

but this is a symlink put in place as a "post-destroot" step (not the Python make install, but by the package manager).

They point to: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Python

which, as confirmed by the "file" command, is a shared library, despite the unusual naming convention.  (Unfortunately, gcc won't understand -lPython in this context, but -F/opt/local/Library/Frameworks -fPython might work because it is a framework.)  This naming convention for shared libraries is standard for Mac OS "frameworks", which don't look like a conventional Linux root directory.  Python was Mac-friendly and made a source release that built into a standard "framework" structure.

Now, the library path hinted at by "python-config" is "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config".  This directory contains a file called "libpython2.6.a", which despite its name, is a symlink to the one and only shared library, which had the file name "Python".  It looks like the Python "make install" put that there, not the MacPorts "post-destroot" step.

Examining "python-config", which is itself a Python script, suggests that the following command could yield a valid value for PYTHON_LIB_LOC:

python -c "from distutils.sysconfig import get_config_var;print get_config_var('LIBPL')"

However, I tried running this command on a CentOS (Red Hat derived distribution, used at my workplace), and found that the config directory contained a **static** library.

The plot thickens: on CentOS, PYTHON_LIB_LOC gets configured as "/usr/lib", but the needed shared library "libpython2.4.so" is in "/usr/lib64", not "/usr/lib".  Yikes!

This should be fixed now in the latest release. The check was improved for OS X.