On 25/04/2010 16:57, Ronald Oussoren wrote:
On 25 Apr, 2010, at 16:43, Michael Foord wrote
On 25/04/2010 15:31, Ronald Oussoren wrote:
On 24 Apr, 2010, at 18:19, Michael Foord wrote:
On 18/04/2010 16:48, Ronald Oussoren wrote:
[snip...]
Michael> A build on my machine produces output similar to:
Michael> Python build finished, but the necessary bits to build these
modules
Michael> were not found:
Michael> _bsddb dl gdbm
* _bsddb and gdbm require external libraries that aren't provided in the system
install
Sorry for duplicating this conversation - just going through my outstanding
emails. Feel free to ignore the one on python-dev.
What are the external libraries? This is probably documented somewhere, so
could you point me to it? (Sorry - my ignorance I know.)
gdbm and bsddb are python wrappers for C libraries that aren't part of OSX, if
you want to use them you have to install those C libraries manually (GNU DBM
and Sleepycat DB).
Is all this documented anywhere? (A description of how to do a "full" build -
all supported modules - on Mac OS X.)
Not that I know. The OSX installers on python.org include more C libraries,
but not everything. The script that creates those installers is in the
repository and it should be easy enough to enhance that to include more
libraries.
Sorry, by creating a "full" build I meant building a Python including
all the libraries that come with the standard installer from python.org.
The sort of documentation I was looking for was not how to extend the
build script - but what third party C libraries need to be installed in
order to perform the standard build.
Probably that doesn't exist either, but I guess if it *did* exist it
would be easier for other people to help by building the installers for
new releases. :-)
readline requires an external library or python 2.6.5, 2.7 or 3.2.
Hmm... I have readline installed (via homebrew). Is that not sufficient?
That should work, but only when setup.py finds that readline install.
How do I configure that? It looks like the location needs to be in
PyBuildExt.compiler.lib_dirs - inherited from
distutils.command.build_ext.build_ext. It doesn't look very easily configurable.
The documentation is a little "terse" (i.e. non-existent):
http://docs.python.org/distutils/apiref.html#module-distutils.command.build_ext
One trick it so add OPT="/my/build/root/include"
LDFLAGS="-L/my/build/root/lib" to the configure line, that way setup.py will look into
/my/build/root/include for headers (and .../lib for library files).
One other thing: the OSX linker looks for dynamic libraries all along its search path
before looking for static libraries, you have to add " -search_paths_first" to
LDFLAGS if you have static libraries that you want to link to which may also be on the
system.
With this configure line:
./configure --prefix=/dev/null --with-pydebug --enable-universalsdk
OPT="/usr/local/include" LDFLAGS="-L/usr/local/lib"
I get the following error on make:
$ make -s
powerpc-apple-darwin10-gcc-4.0.1: /usr/local/include: linker input file
unused because linking not done
i686-apple-darwin10-gcc-4.0.1: /usr/local/include: linker input file
unused because linking not done
lipo: can't figure out the architecture type of:
/var/folders/WD/WDk8J3uFE7OM9tRer5Oy4E+++TI/-Tmp-//cc1ezMQD.out
make: *** [Modules/python.o] Error 1
With:
./configure --prefix=/dev/null --with-pydebug
OPT="/usr/local/include" LDFLAGS="-L/usr/local/lib"
I get a different error on make:
$ make -s
...
i686-apple-darwin10-gcc-4.2.1: /usr/local/include: linker input file
unused because linking not done
ld: in /usr/local/include, can't map file, errno=22
collect2: ld returned 1 exit status
make: *** [Parser/pgen] Error 1
With:
./configure --prefix=/dev/null --with-pydebug
OPT="/usr/local/include" LDFLAGS="-L/usr/local/lib -search_paths_first"
I get the same error on make as above. Looks like getting Python to
build against readline installed with brew maybe tricky.
BTW. If you don't mind getting libedit instead of GNU readline run configure
with 'MACOSX_DEPLOYMENT_TARGET=10.5' (or 10.6) in the shell environment. The
resulting binary will require OSX 10.5 and setup.py will then use the readline
emulation in the system library 'libedit' (it won't do so with the default
options because that generates a binary that runs on 10.3.9 or 10.4 and those
don't have a good enough libedit library). Libedit is a BSD library that
offers simular functionality to GNU readline, but using a different C API and a
different configuration.
Cool - for my own builds that would be fine.
Thanks
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
