I have tried several different combinations of configure args on my Mac in
the past couple days in a so far fruitless attempt to generate a
libpython.2.7.dylib file.  All it will ever generate is a .a file.  I've
come to the conclusion that building a shared Python library is broken, at
least on Macs.  I only even noticed this because I wanted to bundle up a
trivial little Python script as a Mac app build.  py2app requires a dylib
file to generate the app bundle (to include?).

I build in separate build directories so I can have normal, debug and
framework builds.  Here's the configure command from my framework build:

    ../configure --prefix=/Users/skip/local --enable-shared \
        '--enable-framework=/Users/skip/Applications' \
        'CPPFLAGS=-I/Users/skip/local/include -I/opt/local/include' \
        'LDFLAGS=-L/Users/skip/local/lib -L/opt/local/lib'

I've tried taking out the --prefix and/or --enable-shared flags thinking
maybe the --enable-framework flag was sufficient.  I've tried making the
sharedinstall target.  I never see anything like -fPIC or -fpic in the gcc
command line args.  In fact, I don't see "dylib" or "pic" mentioned in the
Makefile at all.

I gave up building in a subdirectory then whittled the configure command
down to this:

    ./configure --prefix=/Users/skip/local --enable-shared \
        '--enable-framework=/Users/skip/Applications'

make clean.  make.  Still no libpython.2.7.dylib file.

Skip

OS X 10.5.5 seems to have the problem just as described, 
whereas there seems no problem on FreeBSD 6.3.

The issue is caused by lack of support for building .dylibs in 
configure.in and Makefile.pre.in. AFAIK this has never worked on OSX.

Fixing that is not entirely trivial (did I mention configure.in is rather 
crufty?).

The attached patch should fix that (the patch touched configure.in, you'll 
have to run autoconf after applying the patch).

Could you please test if the patch fixes the issue for you?

Never mind, the patch won't work. Python's build procedure on unix-y 
platforms assumes that the suffix for shared libraries is the same as that 
for python extentions. That's not true on OSX :-(

I'm working on an updated patch.

I've uploaded a new version of issue4472.patch that seems to do the trick:  
this supports --enable-shared and also still works without that flag.

What is reason to change SO to ".dylib" in configure script and later
Lib/distutils/sysconfig.py to restore it to ".so" ?

Also other builds use $(LDSHARED) to create python shared library. Why
proposed patch introduce inconsistency with other builds and ignore
LDSHARED set by configure script ?

Skip,
Why the issue title is without platform? Shared build is fine on Linux
and Cygwin too.

"SO=.dylib" is needed in the makefile to ensure that "make install" 
works and to ensure that the libpython shared library is build with the 
right suffix (OSX uses .dylib for shared libraries). 

The code in distutils.sysconfig is necessary to ensure that extentions 
are build with a ".so" suffix because the import machinery expected 
'.so' as the suffix.

BTW. I intent to commit the attached patch later this week.

Ronald, 

In proposed patch we see (insert about line 740):
+    	LDLIBRARY='libpython$(VERSION).dylib'
+	BLDLIBRARY='-L. -lpython$(VERSION)'
+	RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH}'


Let see comment in configure script(about line 585):
# MacOSX framework builds need more magic. LDLIBRARY is the dynamic
# library that we build, but we do not want to link against it (we
# will find it with a -framework option). For this reason there is an
# extra variable BLDLIBRARY against which Python and the extension
# modules are linked, BLDLIBRARY. This is normally the same as
# LDLIBRARY, but empty for MacOSX framework builds.


Next on line about 675 we see:
# MacOSX framework builds need more magic. LDLIBRARY is the dynamic
# library that we build, but we do not want to link against it (we
# will find it with a -framework option). For this reason there is an
# extra variable BLDLIBRARY against which Python and the extension
# modules are linked, BLDLIBRARY. This is normally the same as
# LDLIBRARY, but empty for MacOSX framework builds.
if test "$enable_framework"
then
 LDLIBRARY='$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)'
  RUNSHARED=DYLD_FRAMEWORK_PATH="`pwd`:$DYLD_FRAMEWORK_PATH"
  BLDLIBRARY=''
else
  BLDLIBRARY='$(LDLIBRARY)'
fi  

So proposed patch is not consistent with comments. Is expected shared
build to ignore framework build ?


About "SO" - as I understand python build system it is reserved for
module suffix. So there is no reason to change it.

About .dylib - I'm sure that issue can be resolved with appropriate 
update without SO to be changed by configure.

A --enable-framework and --enable-shared are mutable exclusive. You 
either have a regular unix build or a Python.framework.

As to the SO update: the only way to avoid my change is yet another 
variable in the makefile. The "altbininstall" target assumes that it 
will install a shared library named "libpython$(VERSION)$(SO)". I 
haven't looked for other uses of the SO variable in the Makefiles yet.

Is there any documentation on what the role of the "SO" variable means. 
If there isn't I propose to leave my patch as it is. The build 
infrastructure is complicated enough as it is.

> A --enable-framework and --enable-shared are mutable exclusive. You 
> either have a regular unix build or a Python.framework.
May be configure has to block user if both are enabled.

> Is there any documentation on what the role of the "SO" variable means. 
Reading the code (distutils), comments configure script we may get some
information.

From configure (line about 1600) :
AC_DEFINE_UNQUOTED(SHLIB_EXT, "$SO", [Define this to be extension of
shared libraries (including the dot!).])
Actually this is suffix for python module (as example for windows ".pyd"
or "_d.pyd")

If SO is changed by to .dylib for OS X in configure above line will
define SHLIB_EXT to ".dylib" in "pyconfig.h". 

Ronald, you patch restore indirectly shared_lib_extension (distutils) to
".so", but define SHLIB_EXT from "pyconfig.h" will be ".dylib". This may
impact other projects.

The patch seemed to work for me.  Should I worry that I don't see
-fPIC or -fpic in the compile commands?  Also, running "make test"
before at least installing libpython2.7.dylib appears to be impossible:

% otool -L python.exe 
python.exe:
	/Users/skip/local/lib/libpython2.7.dylib (compatibility version 
2.7.0, current version 2.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 111.1.3)
regular% ./python.exe 
dyld: Library not loaded: /Users/skip/local/lib/libpython2.7.dylib
  Referenced from: /Users/skip/src/python/trunk/regular/./python.exe
  Reason: image not found
Trace/BPT trap

Is there a way to work around that?

Skip: 
* GCC always generates position-independent code on OSX

* I'll look in the test issue, that's probably caused by a broken 
definition for RUNSHARED.

Roumen:

* The SHLIB_EXT definition in pyconfig.h is an issue. And I have to 
agree that "SO" is meant to be the suffix for python extension, given 
the comment about LDSHARED in configure.in (just below the definition of 
SHLIB_EXT). 

I'll work on a different way to deal with the .dylib vs. .so problem.

I just finish test for altbininstall make target on linux and cygwin.

Ronald,
About the SO issue - in makefile we may use $(LDLIBRARY) instead of
libpython$(VERSION)$(SO) (see py-issue-4472-makefile.patch).
For cygwin libpython$(VERSION)$(SO) is equal to $(DLLLIBRARY) and
DLLLIBRARY is set only on cygwin.

LDLIBRARY is indeed a good variable to use. 

I've applied issue447-v2.patch in r68146. Backported to 2.6.x in r68147.

Ronald,
cygwin is a special case too.
LDLIBRARY is so called import library !

So the make target can be (as I propose in py-issue-4472-makefile.patch)
+		if test -n "$(DLLLIBRARY)"; then \
+			$(INSTALL_SHARED) $(DLLLIBRARY) $(DESTDIR)$(BINDIR); \

or if new check is not ok then we has to restore old code .
-		if test "$(SO)" = .dll; then \
-			$(INSTALL_SHARED) libpython$(VERSION)$(SO) $(DESTDIR)$(BINDIR); \

More info for cygwin:
- SO = .dll
- DLLLIBRARY is set only for cygwin
- libpython$(VERSION)$(SO) = $(DLLLIBRARY)
- but $(LDLIBRARY) = libpython$(VERSION).dll.a !!!

I've applied this patch. If I understand things correctly that should 
fix the cygwin issue.

Index: Makefile.pre.in
===================================================================
--- Makefile.pre.in	(revision 68149)
+++ Makefile.pre.in	(working copy)
@@ -773,8 +773,8 @@
 	done
 	$(INSTALL_PROGRAM) $(BUILDPYTHON) 
$(DESTDIR)$(BINDIR)/python$(VERSION)$(EXE)
 	if test -f $(LDLIBRARY); then \
-		if test "$(SO)" = .dll; then \
-			$(INSTALL_SHARED) $(LDLIBRARY) 
$(DESTDIR)$(BINDIR); \
+		if test -n "$(DLLLIBRARY)" ; then \
+			$(INSTALL_SHARED) $(DLLLIBRARY) 
$(DESTDIR)$(BINDIR); \
 		else \
 			$(INSTALL_SHARED) $(LDLIBRARY) 
$(DESTDIR)$(LIBDIR)/$(INSTSONAME); \
 			if test $(LDLIBRARY) != $(INSTSONAME); then \

10x cygwin is now not impacted.

Works for me.  Thanks Ronald.  Closing...