[Pythonmac-SIG] problems compiling Python 2.2.1 from source -
pyexpat.c module failure
Bill Bug
William.Bug@drexel.edu
Mon, 10 Jun 2002 15:54:20 -0400
Many thanks to Bill F. & Jack for the helpful suggestions.
Following Bill's instructions to the letter did the trick.
I'd also add the reminder to follow the Python README instructions to
the letter. In particular, if you fail to obey the advice below, you
will not get through the regression tests:
"Mac OS X 10: One of the regular expression tests fails
with a SEGV due to the small stack size used by default, if you
do
"limit stacksize 2048" before "make test" it should work."
With that pre-requisite, I know get the following result from running
the regression tests:
"168 tests OK.
19 tests skipped:
test_al test_cd test_cl test_curses test_dl test_gdbm test_gl
test_imgfile test_linuxaudiodev test_locale test_nis test_ntpath
test_poll test_socket_ssl test_socketserver test_sunaudiodev
test_unicode_file test_winreg test_winsound
1 skip unexpected on darwin:
test_locale"
Now, the only module the python configure/setup.py process can't pick-up
automagically is the one required to run the localization tests. This
is something I believe I can live without, though I'll find out for
certain after testing my connection to Apache, MySQL and postgreSQL.
I may also end up needing some of the other modules that are not
typically loaded in a Darwin install - e.g., socket_ssl, unicode_file,
imgfile, etc. I assume this can be done *relatively* easily by placing
the proper lines in the Modules/Setup.local file prior to running
'configure'.
It sounds like expat will be included as a part of the Python 2.3 source
tree, which will definitely make this process go a little easier.
Thanks again for the help.
Cheers,
Bill
On Saturday, June 8, 2002, at 06:31 PM, bill fancher wrote:
> If you've got the support files, everything Just Works (tm). Here's the
> complete drill for installing 2.2.1 with readline (can't live without
> this)
> and pyexpat:
>
> #download and install readline
> curl -O ftp://ftp.gnu.org/gnu/readline/readline-4.2a.tar.gz
> gnutar xzf readline*.gz
> cd readline-4.2a
> ./configure
> make
> make install
> cd ..
> #download and install expat
> curl -O
> http://telia.dl.sourceforge.net/sourceforge/expat/expat-1.95.3.tar.
> gz
> tar xzf expat-1.95.3.tar.gz
> cd expat-1.95.3
> ./configure
> make
> make install
> cd ..
> #download and install python
> curl -O ftp://ftp.python.org/pub/python/2.2.1/Python-2.2.1.tgz
> tar xzf Python-2.2.1.tgz
> cd Python-2.2.1
> # The following line prevents some warnings (maybe) and turns off debug
> symbols
> # which makes the installation much smaller (~25MB as opposed to ~65MB).
> setenv OPT '-no-cpp-precomp -O3'
> ./configure
> make
> make install
> cd ..
>
> To build as a framework, change the last four lines to:
>
> ./configure --enable-framework
> make
> make frameworkinstall
> cd ..
>
> HTH,
>
> --
> bill
>
> On Saturday, June 8, 2002, at 09:25 AM, John Miller wrote:
>
>> I first want to thank Bill for submitting this detailed information,
>> and second, I want to confirm that exactly the same happened with me
>> on both my desktop and laptop MacOS X machines (except that I didn't
>> '--enable-framework'). If anyone can tell us how to fix this, I'd be
>> very appreciative. I'm glad that Just told us the workaround, but I'm
>> more interested in having the installation process work 'out of the
>> box', if possible.
>>
>> John Miller
>>
>>
>> On Friday, June 7, 2002, at 12:00 PM, Bill Bug <bbug@speakeasy.org>
>> wrote:
>>
>>>
>>> Hi All,
>>>
>>> I've gotten stuck in my attempt to compile Python 2.2.1 from the
>>> source
>>> tarball on my 10.1.5 OS X machine that has the Apple Dev Suite
>>> installed
>>> with a functional gcc compiler.
>>>
>>> Any help/corrections y'all could provide would be greatly appreciated.
>>>
>>> Following the very clear README instructions on how to compile for Mac
>>> OS X, I built the Python core and most all the modules just fine using
>>> the recommended configure command:
>>>
>>> ./configure --enable-framework
>>>
>>> I was even able to get my installed build to pass most all the
>>> <tests>.py.
>>>
>>> All, that is, except for one module I know I need to use - and that
>>> the
>>> 'smart' compile test suite knows should be functional under Darwin &
>>> OS
>>> X. The module in question is pyexpat.o - the Python EXPAT-based XML
>>> Parser module. The SAX module is also not created, since it requires
>>> an
>>> XML parser, which it expects will be coming via pyexpat.o.
>>>
>>> I hunted through the Setup files in the /Modules directory and
>>> uncovered
>>> the line used by setup.py to create the compiler call designed to
>>> build
>>> this package.
>>>
>>> #EXPAT_DIR=/usr/local/src/expat
>>> #pyexpat pyexpat.c -I$(EXPAT_DIR)/xmlparse -L$(EXPAT_DIR) -lexpat
>>>
>>> Unfortunately, my version of OS X does not contain that path, though
>>> it
>>> does contain EXPAT at /usr/local/expat.
>>>
>>> To make a long story a bit shorter, I downloaded the EXPAT source and
>>> compiled it, just to make certain I had all the components required by
>>> pyexpat.c. That placed the files the Python expat module requires -
>>> expat.h & libexpat.a - at /usr/local/include and /usr/local/lib,
>>> respectively. That installation tested just fine.
>>>
>>> I then added the following lines to my
>>> <PYTHON_HOME>/Modules/Setup.local
>>> file:
>>> EXPAT_DIR=/usr/local/
>>> pyexpat pyexpat.c -I$(EXPAT_DIR)/include -L$(EXPAT_DIR)/lib -lexpat
>>>
>>> This info is used by the following code in setup.py to create the call
>>> to the gcc:
>>>
>>> expat_defs = []
>>> expat_incs = find_file('expat.h', inc_dirs, [])
>>> if expat_incs is not None:
>>> # expat.h was found
>>> expat_defs = [('HAVE_EXPAT_H', 1)]
>>> else:
>>> expat_incs = find_file('xmlparse.h', inc_dirs, [])
>>>
>>> if (expat_incs is not None and
>>> self.compiler.find_library_file(lib_dirs, 'expat')):
>>> exts.append( Extension('pyexpat', ['pyexpat.c'],
>>> define_macros = expat_defs,
>>> libraries = ['expat']) )
>>>
>>> The following lines in the 'find_file(filename, std_dirs, paths)
>>> function ultimately define whether the proper gcc call will get
>>> constructed:
>>>
>>> f = os.path.join(dir, filename)
>>> if os.path.exists(f): return []
>>>
>>> Based on these lines, the call expat_incs = find_file('expat.h',
>>> inc_dirs, []) returns an empty array when it finds the 'expat.h' file
>>> at
>>> one of the include paths in 'inc_dirs'. Because of this, the line
>>> 'expat_defs = [('HAVE_EXPAT_H', 1)]' is never run and the
>>> 'HAVE_EXPAT_H'
>>> macro is not defined during compilation.
>>>
>>> This creates the following line in the makefile:
>>> cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp
>>> -fno-common
>>> -dynamic -I. -I./Include -DHAVE_CONFIG_H -I/usr/local/include -c
>>> ./Modules/pyexpat.c -o Modules/pyexpat.o
>>>
>>> which leads to the following stderr msg during compilation:
>>> ./Modules/pyexpat.c:20: xmlparse.h: No such file or directory
>>> make: *** [Modules/pyexpat.o] Error 1
>>>
>>> Examining the pyexpat.c source file shows this line is nested
>>> amongst a
>>> set of pre-proc directives. I've listed these nested booleans below
>>> with the offending line marked with an arrow.
>>>
>>> #ifdef HAVE_EXPAT_H
>>> #include "expat.h"
>>> #ifdef XML_MAJOR_VERSION
>>> #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \
>>> + 0x100 * XML_MINOR_VERSION \
>>> + XML_MICRO_VERSION)
>>> #else
>>> /* Assume the oldest Expat that used expat.h and did not
>>> have version info */
>>> #define EXPAT_VERSION 0x015f00
>>> #endif
>>> #else /* !defined(HAVE_EXPAT_H) */
>>> ---> #include "xmlparse.h"
>>> /* Assume Expat 1.1 unless told otherwise */
>>> #ifndef EXPAT_VERSION
>>> #define EXPAT_VERSION 0x010100
>>> #endif
>>> #endif /* !defined(HAVE_EXPAT_H) */
>>>
>>> A quick scan of the logic confirms what I believe I see in setup.py -
>>> the 'HAVE_EXPAT_H' macro is not getting defined, because 'find_file'()
>>> in setup.py DOES find 'expat.h' at one of the paths in the INCLUDED
>>> directories variable sent into setup.py.
>>>
>>> Have I misunderstood the compiler call in the makefile? Have I
>>> misunderstood what setup.py doing? I can't imagine why it would fail
>>> for this one module and work for all the others. Does that relate to
>>> the fact that the this is the only module being defined via
>>> Setup.local?
>>>
>>> Not surprisingly, the following lines then show up when running the
>>> installation tests, along with many other statements:
>>> ...
>>> test test_pyexpat skipped -- No module named pyexpat
>>> test test_sax skipped -- no XML parsers available
>>> ...
>>> 3 skips unexpected on darwin:
>>> test_sax test_locale test_pyexpat
>>> ...
>>>
>>> Once again, thanks very much for any assistance you can offer.
>>>
>>> Cheers,
>>> Bill Bug
>>> Senior Analyst
>>> Computer Vision Lab for Vertebrate Brain Mapping
>>> MCP/Hahnemann University
>>> Philadelphia, PA, USA 19129
>>
>>
>>
>> _______________________________________________
>> Pythonmac-SIG maillist - Pythonmac-SIG@python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>
>
Bill Bug
Senior Analyst/Ontological Engineer
Computer Vision Laboratory for Vertebrate Brain Mapping (CVLVBM)
MCP/Hahnemann University
2900 Queen Lane
Philadelphia, PA 19129
William.Bug@drexel.edu