[Distutils] building extensions with AIX
Rene Liebscher
R.Liebscher@gmx.de
Mon, 26 Jun 2000 11:40:35 +0200
This is a multi-part message in MIME format.
--------------4F4DEA373079FEB8E3F5E1E5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greg Ward wrote:
>
> Yeah, what the TODO entry fails to mention is that I already tried to
> fix this, in sysconfig.py:
>
> # "Fix" all pathnames in the Makefile that are explicitly relative,
> # ie. that start with "./". This is a kludge to fix the "./ld_so_aix"
> # problem, the nature of which is that Python's installed Makefile
> # refers to "./ld_so_aix", but when we are building extensions we are
> # far from the directory where Python's Makefile (and ld_so_aix, for
> # that matter) is installed. Unfortunately, there are several other
> # relative pathnames in the Makefile, and this fix doesn't fix them,
> # because the layout of Python's source tree -- which is what the
> # Makefile refers to -- is not fully preserved in the Python
> # installation. Grumble.
The problem is the other layout of the installed Python.
Makefile refers to ../././Modules or so, this directory doesn't
exist. The linker scripts are in the same directory as the Makefile
and config.h .
>
> The above fix *ought* to fix the relative pathname problem, but ISTR
> that it didn't work. Don't remember the details.
If you set the paths new, you don't have a relative pathname problem.
>
> Man, why does everyone want to write CCompiler classes all of a sudden!
> ;-)
Because you don't have to change many other files, if you only want to
try a 'bug' workaround?
>
> I'm not sure if this should be fixed early, in sysconfig, or late, in a
> platform-specific UnixCCompiler subclass. Note that there's a similar
> problem with extension-building on OSF/1, and however we fix the AIX
> problem should be how we fix the OSF/1 problem.
>
> Rene, if you cook up new version of this patch, you might just solve
> this problem for me. Try this:
>
> * ditch the code in sysconfig that tries to fix "./" paths
I put it all now in sysconfig.py right after scanning the Makefile.
> * extend the default compiler table, as you suggested, to respect
> sys.platform
It is also done, even if we don't need anymore a seperate compiler class
for AIX. But I included some comments how it would look if we had one.
> Also, do you have access to AIX to test this on? If not, we should bug
> Vladimir Marangazov (Mr. Python-on-AIX). He almost volunteered recently
> on python-dev to test Distutils on AIX, but I didn't get a firm
> commitment out of him. ;-)
If I hadn't access to AIX, I wouldn't write patches, neither I would
need them.
(I tried one of my programs, which uses extensively threads, and this
runs
without problems, so I think it was built correct.)
To be more correct, at my university I have access to Linux, AIX and NT
with
MSVC. (I remember we have here also some Suns.)
At home I can use Linux, FreeBSD3 and NT/Win98 with mingw32/cygwin.
kind regards
Rene Liebscher
--------------4F4DEA373079FEB8E3F5E1E5
Content-Type: text/plain; charset=us-ascii; name="aix_sysconfig.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="aix_sysconfig.patch"
diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/ccompiler.py distutils/distutils/ccompiler.py
--- distutils.orig/distutils/ccompiler.py Mon Jun 26 09:34:34 2000
+++ distutils/distutils/ccompiler.py Mon Jun 26 10:42:47 2000
@@ -801,6 +801,7 @@
# that platform.
default_compiler = { 'posix': 'unix',
'nt': 'msvc',
+# 'aix4': 'aix',
}
# Map compiler types to (module_name, class_name) pairs -- ie. where to
@@ -814,6 +815,8 @@
"Cygwin port of GNU C Compiler for Win32"),
'mingw32': ('cygwinccompiler', 'Mingw32CCompiler',
"Mingw32 port of GNU C Compiler for Win32"),
+# 'aix': ('aixccompiler', 'AIXCCompiler',
+# "unix with AIX specific shared object linking"),
}
def show_compilers():
@@ -839,9 +842,11 @@
dry_run=0,
force=0):
"""Generate an instance of some CCompiler subclass for the supplied
- platform/compiler combination. 'plat' defaults to 'os.name'
- (eg. 'posix', 'nt'), and 'compiler' defaults to the default compiler
- for that platform. Currently only 'posix' and 'nt' are supported, and
+ platform/compiler combination. 'plat' defaults to 'sys.platform'
+ (eg. 'aix4',freebsd3') if a entry for this 'sys.platform' in the
+ default_compiler table exists and os.name' (eg. 'posix', 'nt') otherwise,
+ and 'compiler' defaults to the default compiler for that platform.
+ Currently only 'posix' and 'nt' are supported, and
the default compilers are "traditional Unix interface" (UnixCCompiler
class) and Visual C++ (MSVCCompiler class). Note that it's perfectly
possible to ask for a Unix compiler object under Windows, and a
@@ -849,7 +854,10 @@
'compiler', 'plat' is ignored.
"""
if plat is None:
- plat = os.name
+ if default_compiler.has_key(sys.platform):
+ plat = sys.platform
+ else:
+ plat = os.name
try:
if compiler is None:
diff -BurN --minimal --exclude=*.pyc distutils.orig/distutils/sysconfig.py distutils/distutils/sysconfig.py
--- distutils.orig/distutils/sysconfig.py Mon Jun 26 09:34:35 2000
+++ distutils/distutils/sysconfig.py Mon Jun 26 11:19:19 2000
@@ -257,7 +257,21 @@
raise DistutilsPlatformError, my_msg
parse_makefile(file, g)
-
+
+ # on AIX there are wrong paths to the linker scripts in the Makefile
+ # (these paths are relative to the python source, but if installed
+ # these scripts are in another directory)
+ if sys.platform == 'aix4': # what is with AIX 3.x ?
+ g['LDSHARED'] = string.join([
+ # linker script is in the config directory, not in the
+ # Modules as the Makefile says
+ os.path.join(get_python_lib(standard_lib=1),
+ 'config','ld_so_aix'),
+ ' ', g['CC'],
+ ' ', '-bI:', # where is python's exports file
+ os.path.join(get_python_lib(standard_lib=1),
+ 'config','python.exp')
+ ],'') # <= all spaces are explicitly specified
def _init_nt():
"""Initialize the module as appropriate for NT"""
--------------4F4DEA373079FEB8E3F5E1E5--