| Subject: AIX - Misc/AIX-NOTES |
| From: Vladimir Marangozov <Vladimir.Marangozov@imag.fr> |
| To: guido@CNRI.Reston.Va.US (Guido van Rossum) |
| Date: Wed, 6 Aug 1997 11:41:00 +0200 (EET) |
| |
| ============================================================================== |
| COMPILER INFORMATION |
| ------------------------------------------------------------------------------ |
| |
| (1) A problem has been reported with "make test" failing because of "weird |
| indentation." Searching the comp.lang.python newsgroup reveals several |
| threads on this subject, and it seems to be a compiler bug in an old |
| version of the AIX CC compiler. However, the compiler/OS combination |
| which has this problem is not identified. In preparation for the 1.4 |
| release, Vladimir Marangozov (Vladimir.Marangozov@imag.fr) and Manus Hand |
| (mhand@csn.net) reported no such troubles for the following compilers and |
| operating system versions: |
| AIX C compiler version 3.1.2 on AIX 4.1.3 and AIX 4.1.4 |
| AIX C compiler version 1.3.0 on AIX 3.2.5 |
| If you have this problem, please report the compiler/OS version. |
| |
| (2) Stefan Esser (se@MI.Uni-Koeln.DE), in work done to compile Python |
| 1.0.0 on AIX 3.2.4, reports that AIX compilers don't like the LANG |
| environment varaiable set to European locales. This makes the compiler |
| generate floating point constants using "," as the decimal seperator, |
| which the assembler doesn't understand (or perhaps it is the other way |
| around, with the assembler expecting, but not getting "," in float |
| numbers). "LANG=C; export LANG" solves the problem, as does |
| "LANG=C $(MAKE) ..." in the master Makefile. |
| |
| (3) The cc (or xlc) compiler considers "Python/ceval.c" too complex to |
| optimize, except when invoked with "-qmaxmem=4000" |
| |
| (4) Some problems (due to _AIX not being #defined) when python 1.0.0 was |
| compiled using 'gcc -ansi' were reported by Stefan Esser, but were not |
| investigated. |
| |
| (5) The cc compiler has internal variables named "__abs" and "__div". These |
| names are reserved and may not be used as program variables in compiled |
| source. (As an anecdote in support of this, the implementation of |
| Python/operator.c had this problem in the 1.4 beta releases, and the |
| solution was to re#define some core-source variables having these names, |
| to give these python variables different names if the build is being done |
| on AIX.) |
| |
| (6) As mentioned in the README, builds done immediately after previous builds |
| (without "make clean" or "make clobber") sometimes fail for mysterious |
| reasons. There are some unpredictable results when the configuration |
| is changed (that is, if you "configure" with different parameters) or if |
| intermediate changes are made to some files. Performing "make clean" or |
| "make clobber" resolves the problems. |
| |
| ============================================================================== |
| THREAD SUPPORT |
| ------------------------------------------------------------------------------ |
| |
| As of AIX version 4, there are two (incompatible) types of pthreads on AIX: |
| a) AIX DCE pthreads (on AIX 3.2.5) |
| b) AIX 4 pthreads (on AIX 4.1 and up) |
| Support has been added to Python to handle the distinction. |
| |
| The cc and gcc compilers do not initialize pthreads properly. The only |
| compilers that can initialize pthreads properly are IBM *_r* compilers, |
| which use the crt0_r.o module, and which invoke ld with the reentrant |
| version of libc (libc_r). |
| |
| In order to enable thread support, follow these steps: |
| 1. Uncomment the thread module in Modules/Setup |
| 2. configure --without-gcc --with-thread ... |
| 3. make CC="cc_r" OPT="-O -qmaxmem=4000" |
| |
| For example, to make with both threads and readline, use: |
| ./configure --without-gcc --with-thread --with-readline=/usr/local/lib |
| make CC=cc_r OPT="-O2 -qmaxmem=4000" |
| |
| If the "make" which is used ignores the "CC=cc_r" directive, one could alias |
| the cc command to cc_r (for example, in C-shell, perform an "alias cc cc_r"). |
| |
| Vladimir Marangozov (Vladimir.Marangozov@imag.fr) provided this information, |
| and he reports that a cc_r build initializes threads properly and that all |
| demos on threads run okay with cc_r. |
| |
| ============================================================================== |
| SHARED LIBRARY SUPPORT |
| ------------------------------------------------------------------------------ |
| |
| AIX shared library support was added to Python in the 1.4 release by Manus |
| Hand (mhand@csn.net) and Vladimir Marangozov (Vladimir.Marangozov@imag.fr). |
| |
| Python modules may now be built as shared libraries on AIX using the normal |
| process of uncommenting the "*shared*" line in Modules/Setup before the |
| build. |
| |
| AIX shared libraries require that an "export" and "import" file be provided |
| at compile time to list all extern symbols which may be shared between |
| modules. The "export" file (named python.exp) for the modules and the |
| libraries that belong to the Python core is created by the "makexp_aix" |
| script before performing the link of the python binary. It lists all global |
| symbols (exported during the link) of the modules and the libraries that |
| make up the python executable. |
| |
| When shared library modules (.so files) are made, a second shell script |
| is invoked. This script is named "ld_so_aix" and is also provided with |
| the distribution in the Modules subdirectory. This script acts as an "ld" |
| wrapper which hides the explicit management of "export" and "import" files; |
| it adds the appropriate arguments (in the appropriate order) to the link |
| command that creates the shared module. Among other things, it specifies |
| that the "python.exp" file is an "import" file for the shared module. |
| |
| At the time of this writing, neither the python.exp file nor the makexp_aix |
| or ld_so_aix scripts are installed by the make procedure, so you should |
| remember to keep these and/or copy them to a different location for |
| safekeeping if you wish to use them to add shared extension modules to |
| python. However, if the make process has been updated since this writing, |
| these files MAY have been installed for you during the make by the |
| LIBAINSTALL rule, in which case the need to make safe copies is obviated. |
| |
| If you wish to add a shared extension module to the language, you would follow |
| the steps given in the example below (the example adds the shared extension |
| module "spam" to python): |
| 1. Make sure that "ld_so_aix" and "makexp_aix" are in your path. |
| 2. The "python.exp" file should be in the current directory. |
| 3. Issue the following commands or include them in your Makefile: |
| cc -c spammodule.c |
| ld_so_aix cc spammodule.o -o spammodule.so |
| |
| For more detailed information on the shared library support, examine the |
| contents of the "ld_so_aix" and "makexp_aix" scripts or refer to the AIX |
| documentation. |
| |
| NOTE: If the extension module is written in C++ and contains templates, |
| an alternative to "ld_so_aix" is the /usr/lpp/xlC/bin/makeC++SharedLib |
| script. Chris Myers (myers@TC.Cornell.EDU) reports that ld_so_aix |
| works well for some C++ (including the C++ that is generated |
| automatically by the Python SWIG package [SWIG can be found at |
| http://www.cs.utah.edu/~beazley/SWIG/swig.html]). However, it is not |
| known whether makeC++SharedLib can be used as a complete substitute |
| for ld_so_aix. |
| |
| ============================================================================== |