quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MODPYTHON-65) 3.2 working version will not install on Mac OS X (10.3.7)
Date Fri, 22 Jul 2005 02:07:45 GMT
    [ http://issues.apache.org/jira/browse/MODPYTHON-65?page=comments#action_12316435 ] 

Graham Dumpleton commented on MODPYTHON-65:

The problem here is that on Mac OS X, distutils compiles Python
loadable modules in a way that expects all symbols to be resolvable
at the time the module is created. That is, all symbols must be present
in either the objects being linked into the module or in libraries which
are explicitly linked with the module.

In a scenario like mod_python where there will be undefined references
to symbols which are only defined within the executable running the
interpreter into which the module is loaded, this will fail.

Previously this wasn't a problem because distutils wasn't used to
create the module and instead the makefile use libtool to do it. One of
the options to libtool was "--silent". This option (at least I think so, it may
be a different option), would underneath pass appropriate options to
the linker for a platform to disable undefined symbols causing an error.

Since distutils is now used, there is going to have to be platform specific
hacks to add additional options to the link line when creating a module
to add these platform specific options. This however is not as simple as
defining extra_link_flags to the distutils extension object as they will only
be placed at the end. These magic options tend to be positional
dependent and need to be included at a specific spot early in the
link line. The distutils package does not give you this level of control
through its public APIs and thus a hack is required which delves into
its private parts. If distutils changes, like it did from 2.2 to 2.3, this hack
will break and no longer work.

This problem may affect other platforms besides MacOSX as there are
other platforms that also require specific options to ignore undefined

Anyway, the hack required to get this to work for Mac OS X with Python 2.3
is as follows. If you know of a better way, by all means let me know. :-)

Index: dist/setup.py.in
--- dist/setup.py.in    (revision 220194)
+++ dist/setup.py.in    (working copy)
@@ -85,7 +85,7 @@
     """returns apache lib directory"""
     apache_srcdir = getapache_srcdir()
     if apache_srcdir is None:
-        return ""
+        return getapxs_option("LIBDIR")
         return os.path.join(apache_srcdir, "lib")
@@ -153,6 +153,17 @@
     scripts = []
     data_files = []
+import string
+from distutils import sysconfig
+if sys.platform == "darwin":
+    sysconfig._config_vars["LDSHARED"] = \
+            string.replace(sysconfig.get_config_var("LDSHARED"), \
+            " -bundle "," -bundle -flat_namespace -undefined suppress ")
+    sysconfig._config_vars["BLDSHARED"] = \
+            string.replace(sysconfig.get_config_var("BLDSHARED"), \
+            " -bundle "," -bundle -flat_namespace -undefined suppress ")
       description="Apache/Python Integration",

> 3.2 working version will not install on Mac OS X (10.3.7)
> ---------------------------------------------------------
>          Key: MODPYTHON-65
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-65
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.2.0
>  Environment: Mac OS X (10.3.7)
>     Reporter: Graham Dumpleton

> Something is wrong with configure or setup.py file.
> /usr/bin/python setup.py build
> running build
> running build_py
> running build_ext
> building 'mod_python_so' extension
> gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/mod_python.o
-L -lapr-0 -laprutil-0 -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/mod_python_so.so
> ld: -L: directory name missing
> error: command 'gcc' failed with exit status 1
> More later when I have a chance to work out what is wrong.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message