homepage

On a MacOS X framework build, the LINKFORSHARED variable obtained from 
distutils.sysconfig.get_config_vars() has the value
 -u _PyMac_Error Python.framework/Versions/2.5/Python
The last item is incomplete, it needs to be prefixed with the path in 
which the Python framework is installed.
Looking at config/Makefile (from which Distutils takes the variables), I 
find
LINKFORSHARED=	-u _PyMac_Error 
$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)
and
PYTHONFRAMEWORKDIR=	Python.framework
One fix would be to use PYTHONFRAMEWORKINSTALLDIR instead of PYTHONFRAMEWORKDIR in the definition of LINKFORSHARED, but I don't know 
if this could have undesirable effects on the build process.

I confirm this issue, some handy workaround available?

The solution I found is:
LINKFORSHARED = -u _PyMac_Error -framework Python
as in the Apple included Python Makefile
and
LDFLAGS += -F$(PYTHONFRAMEWORKPREFIX)
that makes linker use the right framework (not sure, but works with
MacPython installed)

I can add that providing the option:
-mmacosx-version-min=10.4
or setting the anv var
MACOSX_DEPLOYMENT_TARGET=10.4
is it possible to build an extension in MacPython.org too
(without that option there was a problem with some 10.5 libs)

This bug is still present in Python 2.6 and Python 3.0 included with
Snow Leopard.
Code:
/Library/Frameworks/Python.framework/Versions/3.0/bin/python
Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>> import distutils.sysconfig
>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))
returns:
 Python.framework/Versions/3.0/Python
and
/Library/Frameworks/Python.framework/Versions/2.6/bin/python
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
>> import distutils.sysconfig
>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))
Returns:
 -u _PyMac_Error Python.framework/Versions/2.6/Python
However,
/usr/bin/python
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
>> import distutils.sysconfig
>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))
returns the correct path:
 -u _PyMac_Error
/System/Library/Frameworks/Python.framework/Versions/2.6/Python

Correction to my last message: the first two Python installations,
located at /Library/Frameworks/Python.framework/Versions/ did not come
with Snow Leopard, I installed them from MacPython packages. The Snow
Leopard version (/usr/bin/python) does not seem affected by the bug.
I just installed the latest MacPython stable packages (2.6.4 and 3.1.1),
and the relative path bug is still present. Here's the result for 3.1.1:
--$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3
Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> print(distutils.sysconfig.get_config_var('LINKFORSHARED'))
-framework CoreFoundation Python.framework/Versions/3.1/Python

What do you use LINKFORSHARED for?
As a minor rant: the wholesale export of all settings in the main 
Makefile through distutils sucks big time. I have no idea whether or not 
LINKFORSHARED is meant to be a public API, and if it is what it should 
be used for.
The value of LINKFORSHARED is correct for building the framework, making 
sure that the value is useful outside of the build of Python itself 
would almost certainly require hacks, either in the makefile or by 
patching the Makefile during installation.
BTW. I have no idea what's the point of msg75511, it doesn't seem to be 
related to the original report.

I am using it to tell CMake where are the Python Libraries for linking.
Here's a snippet from my FindPythonLibs.cmake (I am attaching the whole
file as well):
...
EXECUTE_PROCESS(COMMAND ${PYTHON_EXECUTABLE} -c "import
distutils.sysconfig\nprint
distutils.sysconfig.get_config_var('LINKFORSHARED')"
 OUTPUT_VARIABLE PYTHON_LDFLAGS_OUTPUT_VARIABLE
 ERROR_VARIABLE PYTHON_LDFLAGS_ERROR_VARIABLE
 RESULT_VARIABLE PYTHON_LDFLAGS_RETURN_VALUE
 )
...
Does anybody happen to know a better/more correct way for linking the
python libs?

python-config (or python3-config for python 3.x) is the best way to get 
this information in recent versions of python (IIRC 2.6 or newer)

Thank you! That's much more convenient.
So maybe then this bug report should be closed without a fix, right?

To be honest: I don't know.
Tarek: do you think LINKFORSHARED should contain a value that works 
outside of Python's build environment?

I agree with Ronald: making sure all variables in Makefile provide
values that can work in any environment just because distutils offers an
API to read them would be a major pain.
What is planned is to remove sysconfig from distutils, and have it in
the stdlib, with a private module built when ./configure is called, that
would contain these variables. 
And maybe we could filter out some variables in this process to keep
only the ones that can be used by code in all environments.
IOW, if python-config provides what you need, LINKFORSHARED could be
filtered out so the API cannot return it.

Was this actually fixed? As per <http://bugs.python.org/issue16848> it affects "python-config --ldflags" which is used by various build systems.