Hi, I have seen in the TODO file that there was an entry about AIX. I tried it and found some little problems. It seems some paths in the Makefile are wrong. After playing a little bit around with it, I wrote a new compiler class. (I think, these changes could be included in unixccompiler, but to test it, it is nice to have a own file for it.) Maybe we should also change the default compiler table. I think we should have entries for sys.platform in it, too. So we could try a more specific name first ('aix4') and if there is no entry the usual os.name ('posix'.) The AIXCCompiler class is attached, maybe someone wants to try it, and find out if this is really all we have to change against the standard unixccompiler. (Don't forget to make an entry for it in ccompiler.py.) kind regards Rene Liebscher PS: I used AIX 4.3 and its 'cc' compiler. """distutils.aixccompiler Contains the AIXCCompiler class, a subclass of UnixCCompiler that handles some path problems with AIX. The makefile isn't correct for distutils' standard compiler. """ # created 2000/06/23, Rene Liebscher __revision__ = "$Id: aixccompiler.py $" from distutils import sysconfig from distutils.unixccompiler import UnixCCompiler # XXX Things not currently handled: # * see UnixCCompiler class AIXCCompiler (UnixCCompiler): compiler_type = 'aix' def __init__ (self, verbose=0, dry_run=0, force=0): UnixCCompiler.__init__ (self, verbose, dry_run, force) # we have to correct some paths self.ld_shared=sysconfig.get_python_lib(standard_lib=1)+'/config/ld_so_aix' self.ldflags_shared.append('-bI:'+sysconfig.get_python_lib(standard_lib=1)+'/config/python.exp') # __init__ () # class AIXCCompiler
On 23 June 2000, Rene Liebscher said:
I have seen in the TODO file that there was an entry about AIX.
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. from os.path import normpath, join, dirname for (name, value) in done.items(): if value[0:2] == "./": done[name] = normpath(join(dirname(fp.name), value))
I tried it and found some little problems. It seems some paths in the Makefile are wrong.
The above fix *ought* to fix the relative pathname problem, but ISTR that it didn't work. Don't remember the details.
After playing a little bit around with it, I wrote a new compiler class. (I think, these changes could be included in unixccompiler, but to test it, it is nice to have a own file for it.)
Man, why does everyone want to write CCompiler classes all of a sudden! ;-) 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 * fix your code so it fits in less than 80 columns, uses os.path.join instead of "+", and puts spaces around the "=" in assignments (but *not* default or keyword arguments) * extend the default compiler table, as you suggested, to respect sys.platform 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. ;-) Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ I just read that 50% of the population has a below median IQ!
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 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"""
On 26 June 2000, Rene Liebscher said:
* 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.
OK, I've squirrelled this away in my "patches" directory for a rainy day. If it's not needed for the AIX hack, it's not needed (yet). Your fix to sysconfig.py looked right in spirit, but I totally rewrote it. Give it a whirl and let me know if I broke anything. Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ I once decorated my apartment entirely in ten foot salad forks!!
participants (2)
-
Greg Ward -
Rene Liebscher