Re: [Python-Dev] Cross compiling C-python 2.7.10 maintenance release for ARM on 64 bit x86_64 systems.

[R. David Murray]

On Tue, 14 Jul 2015 10:22:05 -, Andrew Robinson andr...@r3dsolutions.com 
wrote:
 I'm trying to cross compile C-python 2.7.10 for an embedded system. (Eg: 
 a Kobo reader).
 But there appears to be some bugs that do not allow the latest 
 maintenance release of Python to correctly cross compile on an x86-64 
 build system, for a 32 bit arm system.

To my understanding we don't yet fully support this (though we'd like
to), because we don't have a buildbot that regularly does cross compiles.
There are open issues in the tracker, perhaps you can vet and/or submit
some patches.[*]  Or contribute a buildbot?

--David

[8} See eg http://bugs.python.org/issue5404; I'm guessing there are others.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Cross compiling C-python 2.7.10 maintenance release for ARM on 64 bit x86_64 systems.

[Andrew Robinson]

Hi.

I'm trying to cross compile C-python 2.7.10 for an embedded system. (Eg: 
a Kobo reader).
But there appears to be some bugs that do not allow the latest 
maintenance release of Python to correctly cross compile on an x86-64 
build system, for a 32 bit arm system.


I have researched the problem, and there are apparently two different bugs;
1'st -- the Makefile doesn't disable PYTHONPATH for the arm libraries, 
and the x86 64 bit platform will attempt to link to the arm libraries 
during the compile process producing an wrong elf class error.


I found some online examples of cross compiling older versions of python 
which suggest adding a '-' before PYTHONPATH' to prevent that from 
happening.  When I do that, it does compile -- but:


2'nd -- If I build python 2.7.10 with the above change, and with no 
debugging information or switches; it builds fine, but the resulting 
binary segfaults randomly on the Kobo reader, and will not import 
libraries without segfaulting.


If I build it with all available debugging information (-g3 -ggdb 
-gdwarf 4), the random segfaulting stops -- and instead, python raises 
an exception any time I attempt to import a library.


---
Python 2.7.10 (default, Jun 29 2015, 23:00:31)
[GCC 4.8.1 20130401 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
 import math
Traceback (most recent call last):
  File stdin, line 1, in module
ImportError: /mnt/user/lib/python2.7/lib-dynload/math.so: undefined 
symbol: Py_InitModule4

[40857 refs]

-

The symbol is indeed missing when I check with nm, and from what little 
information I can find online -- this appears to have something to do 
with a 32 bit vs. 64 bit incompatibility; eg: even though it's compiling 
for 32 bits ARM -- it still seems to be trying to use symbols associated 
with 64 bit processing.


I attempted to compile a 32 bit python interpreter on the build system, 
to make PYTHON_FOR_BUILD, and PGEN_FOR_BUILD ; but it didn't rectify the 
problem.


What is the proper way to cross compile 2.7.10 for 32 bit arm, on a 
x86_64 bit platform  / what am I doing wrong ?


-- 


Supplimentary information:

I'm using the linaro-gcc compiler from the kobolabs git repository, () 
eg: an arm-linux-gnueabihf-gcc on a 64 bit Slackware 14.1 machine with 
multilib x86 gcc available on the build system.


I have a separate 8GB partition with the Kobo kernel source code, 
stdlibs, etc. all installed from the github source and compiled to a 
target directory stored in an environment variable called ${DEVICEROOT} 
; All files found on the KOBO reader are located under ${DEVICEROOT} on 
the BUILD machine, and the arm GCC processor uses -I 
${DEVICEROOT}/usr/include and other appropriate paths so that GCC finds 
them naturally.


The following bash script shows the steps I used to compile Python with 
-- and it is followed by another bash script which sets up the compile 
environment variables, so you can see how the compiler environment is 
configured.


I have no problem compiling C source code in general using the Kobo 
compiler tools, and have compiled gnuplot, and bash, and several other 
packages with absolutely no problems.  It is only python which is not 
compiling correctly.


-- 



set -x

# A parser generator and build system version of python are supposed to be
# needed to run parts of the cross compilation;  I do see python used in 
the

# Makefile, but no references to a buid version of PGEN are defined,
# so I don't know if PGEN gets used or not -- but I build it anyway...
# As this is what receipies on the web say to do...

make distclean
(
. /etc/profile.d/32dev.sh
export LIBDIRSUFFIX=
./configure # --build=x86_64-unknown-linux-gnu 
--host=i486-unknown-linux-gnu #(uncomment to build 32bit)


make Parser/pgen python
mv python python_for_build
mv Parser/pgen Parser/pgen_for_build
make distclean
)

# fix setup.py to handle installing to the target system's fake install
# directory found on the build system at $DEVICEROOT.

# We want utf-8, unicode terminal handling -- so make sure python compiles
# with ncursesw substituted for curses.

CURSESFLAGS=`pkg-config --cflags ncursesw`

# Configure python to be built
CFLAGS=${CFLAGS} ${CURSESFLAGS} -g3 -ggdb -gdwarf-4 ./configure 
--host=${CROSSTARGET} --build=i486-unknown-linux-gnu --enable-unicode 
--enable-shared --with-pydebug --prefix=/mnt/user --disable-ipv6 
--without-pymalloc ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no 
ac_cv_have_long_long_format=yes PYTHON_FOR_BUILD=${PWD}/python_for_build 
PGEN_FOR_BUILD=${PWD}/Parser/pgen_for_build


# Fix a bug in the Makefile
# The 

Re: [Python-Dev] Cross compiling Python (for Android)

[Stefan Krah]

Frank, Matthew I matthew.i.frank at intel.com writes:
  
 4. Module _decimal is failing to compile.  The problem is that it has
    a header called memory.h.  Android's libc has the problem that
    /usr/include/stdlib.h includes memory.h.  But the build system
    puts -I. on the include path before the system dirs (as it should)
    so when compiling _decimal, Modules/_decimal/libmpdec/memory.h gets
    found instead of /usr/include/memory.h.  Shiz has a patch here:
   
https://github.com/rave-engine/python3-android/blob/master/mk/python/3.3.5/p\
 ython-3.3.5-android-libmpdec.patch
    (which renames memory.h - mpmemory.h) but I don't know
  
    a.  Is there a tracker for this yet?  and
    b.  Is Shiz's fix the desired one or should I be looking for
    another approach?  (Maybe modifying the -I flags for the build
    of just the build of _decimal or something?)

I think using memory.h in an application is standard conforming.
Since _decimal compiles on all other Linux platforms, it may be worth
reporting this to the Android developers and see if they can fix it
(possibly by not including memory.h in stdlib.h).

FWIW, OCaml also has a memory.h header.


Stefan Krah

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cross compiling Python (for Android)

[Guido van Rossum]

Hi Frank,

Nobody has responded to you yet, but don't feel discouraged by that! The
core Python development group consists mostly of people who don't develop
mobile apps in their day jobs, and they may feel reluctant to maintain
changes that they can't personally test. (And I don't expect it would be
easy to set up Android or iOS buildbots either.)

But there are definitely people trying to use Python to develop mobile apps
(e.g. Kivy). Today there was a similar post to python-ideas about this. I
think the world may soon be eager to develop mobile apps in Python (the
platforms are maturing and the processors are getting faster), and Python
should be ready for this change in attitude.

Hopefully we can get some good patches in for the next bugfix releases of
Python 2.7 and 3.4, as well as the upcoming 3.5 alphas and betas.

Of course, the Kivy approach might work for some time yet (they have a set
of patches for Python 2.7.1 or 2.7.2), but it would be better if that
wasn't necessary, and Python could be build (with the right dev
environment) for iOS and Android.

A word of advice: the specific patches you have should probably be
submitted to the Python issue tracker (bugs.python.org). Also, several
smaller patches are more likely to be reviewed and checked in timely than
one mega-patch.

Good luck!

--Guido

On Thu, Oct 23, 2014 at 12:22 PM, Frank, Matthew I 
matthew.i.fr...@intel.com wrote:

  This email is about my experience getting CPython (3.4.1) to

 cross-compile and run on x86 Android (4.4.2 with sdk 19 and ndk-r9).

 I know that Android is not a supported architecture (and I won't

 regale you with stories about the complete locale and mbstowcs support

 I had to borrow from FreeBSD to get it working).  The purpose of this

 email is that several things I found are arguably bugs in the Python

 build system or code when it comes to cross-compiling that are exposed

 by Android's poor Posix support.  I'd like some advice about what kind

 of patch (if any) would be most suitable for fixing the problems on

 the Python side.



 Just to be complete:  I'm configuring with



  CPPFLAGS=-I../my-locale ../Python-3.4.1/configure --enable-shared

  --prefix=/path/to/install/dir --build=x86_64-linux-gnu

  --host=i686-linux-android --disable-ipv6 ac_cv_file__dev_ptmx=no

  ac_cv_file__dev_ptc=no ac_cv_little_endian_double=yes



 (The CPPFLAGS addition is to get the headers for my locale fixes

 instead of the default Android ones.  ac_cv_file__dev_ptmx=no and

 ac_cv_file__dev_ptc=no are because I don't have /dev/whatever on my

 build machine.  ac_cv_little_endian_double is because configure for

 cross builds can't figure out the endianness of doubles on the host

 (because it is running on the build machine not the host.)  (For ARM

 it would be ac_cv_mixed_endian_double=yes.)



 I've gotten to the point where `make; make install` succeeds up to the

 point of building something that runs on my Android system (from the

 command line) and `python -m test` runs 388 tests, with 321 ok, 24

 test failures and 43 tests skipped (the skips mostly due, I think, to

 me not yet having installed the right cross-building support for

 things like bz2 and dbm.)



 1. `make` succeeds but `make install` always fails at the end with

something having to do with being unable to run ensurepip

(presumably because ensurepip requires modules that only run on the

host, not the build module.)  So it seems this should be wrapped in

a test for cross compilation, but I haven't looked at exactly what

yet.  The error is:



/linux-python/bin/python3.4: Error while finding spec for

'ensurepip.__main__' (class 'ImportError':

/build-directory/build/lib.linux-i686-3.4/time.cpython-34m.so:

wrong ELF class: ELFCLASS32); 'ensurepip' is a package and cannot

be directly executed make: *** [install] Error 1



 2. setup.py is missing -lm flag for several modules.  On Linux this

problem is hidden because libm is already loaded by the executable

calling dlopen(), but Android's loader deals with unknown symbols

differently (searches only the libs explicitly linked against the

module being loaded.)  http://bugs.python.org/issue21668 reports

the problem for selectmodule (can't find ceil()) and timemodule

(fmod() and floor()).  But there are at least two more: audioop

fails to load because it needs floor() and ctypes_test fails to

load because it needs sqrt().  I'll happily update the patch in

21668.



Is there any fundamental objection to adding the -lm flag to the

link step where it is necessary?



 3. What is ossaudiodev?  It tries to include sys/soundcard.h, which

I don't have on my system.   (The rule in setup.py is

wrapped in a test for host of Linux/FreeBSD/Darwin, but Android x86

gets configured with --host=i686-linux-android so to turn it off

requires an extra test for and not cross_compiling.)

[Python-Dev] Cross compiling Python (for Android)

[Frank, Matthew I]

This email is about my experience getting CPython (3.4.1) to
cross-compile and run on x86 Android (4.4.2 with sdk 19 and ndk-r9).
I know that Android is not a supported architecture (and I won't
regale you with stories about the complete locale and mbstowcs support
I had to borrow from FreeBSD to get it working).  The purpose of this
email is that several things I found are arguably bugs in the Python
build system or code when it comes to cross-compiling that are exposed
by Android's poor Posix support.  I'd like some advice about what kind
of patch (if any) would be most suitable for fixing the problems on
the Python side.

Just to be complete:  I'm configuring with

 CPPFLAGS=-I../my-locale ../Python-3.4.1/configure --enable-shared
 --prefix=/path/to/install/dir --build=x86_64-linux-gnu
 --host=i686-linux-android --disable-ipv6 ac_cv_file__dev_ptmx=no
 ac_cv_file__dev_ptc=no ac_cv_little_endian_double=yes

(The CPPFLAGS addition is to get the headers for my locale fixes
instead of the default Android ones.  ac_cv_file__dev_ptmx=no and
ac_cv_file__dev_ptc=no are because I don't have /dev/whatever on my
build machine.  ac_cv_little_endian_double is because configure for
cross builds can't figure out the endianness of doubles on the host
(because it is running on the build machine not the host.)  (For ARM
it would be ac_cv_mixed_endian_double=yes.)

I've gotten to the point where `make; make install` succeeds up to the
point of building something that runs on my Android system (from the
command line) and `python -m test` runs 388 tests, with 321 ok, 24
test failures and 43 tests skipped (the skips mostly due, I think, to
me not yet having installed the right cross-building support for
things like bz2 and dbm.)

1. `make` succeeds but `make install` always fails at the end with
   something having to do with being unable to run ensurepip
   (presumably because ensurepip requires modules that only run on the
   host, not the build module.)  So it seems this should be wrapped in
   a test for cross compilation, but I haven't looked at exactly what
   yet.  The error is:

   /linux-python/bin/python3.4: Error while finding spec for
   'ensurepip.__main__' (class 'ImportError':
   /build-directory/build/lib.linux-i686-3.4/time.cpython-34m.so:
   wrong ELF class: ELFCLASS32); 'ensurepip' is a package and cannot
   be directly executed make: *** [install] Error 1

2. setup.py is missing -lm flag for several modules.  On Linux this
   problem is hidden because libm is already loaded by the executable
   calling dlopen(), but Android's loader deals with unknown symbols
   differently (searches only the libs explicitly linked against the
   module being loaded.)  http://bugs.python.org/issue21668 reports
   the problem for selectmodule (can't find ceil()) and timemodule
   (fmod() and floor()).  But there are at least two more: audioop
   fails to load because it needs floor() and ctypes_test fails to
   load because it needs sqrt().  I'll happily update the patch in
   21668.

   Is there any fundamental objection to adding the -lm flag to the
   link step where it is necessary?

3. What is ossaudiodev?  It tries to include sys/soundcard.h, which
   I don't have on my system.   (The rule in setup.py is
   wrapped in a test for host of Linux/FreeBSD/Darwin, but Android x86
   gets configured with --host=i686-linux-android so to turn it off
   requires an extra test for and not cross_compiling.)

   Can I just turn off ossaudiodev for cross compiling or might
   someone want it in a different type of cross build?  (In which case
   I think I'll have to write some kind autoconf rule for it, which I
   don't quite know how to do yet.)

4. Module _decimal is failing to compile.  The problem is that it has
   a header called memory.h.  Android's libc has the problem that
   /usr/include/stdlib.h includes memory.h.  But the build system
   puts -I. on the include path before the system dirs (as it should)
   so when compiling _decimal, Modules/_decimal/libmpdec/memory.h gets
   found instead of /usr/include/memory.h.  Shiz has a patch here:
   https://github.com/rave-engine/python3-android/blob/master/mk/python/3.3.5/p\
ython-3.3.5-android-libmpdec.patch
   (which renames memory.h - mpmemory.h) but I don't know

   a.  Is there a tracker for this yet?  and
   b.  Is Shiz's fix the desired one or should I be looking for
   another approach?  (Maybe modifying the -I flags for the build
   of just the build of _decimal or something?)

5. I'm not sure what test configure is actually doing for gethostby*()
   in a cross-compile environment.  In any case Android has a bug
   where gethostbyaddr_r() is declared in the headers, but not
   actually implemented in libc.  So I have to modify my pyconfig.h by
   hand to define HAVE_GETHOSTBYNAME and undef HAVE_GETHOSTBYNAME_R
   and HAVE_GETHOSTBYNAME_R_6_ARG.

   Is there a variable (like ac_cv_little_endian_double) that I can
   give to `configure` to make 

Re: [Python-Dev] cross-compiling patches

[Matthias Klose]

On 30.06.2012 23:17, Antoine Pitrou wrote:
 
 Hello,
 
 I think these patches are premature (they break compilation on OS X,
 and they break ctypes configure on my Linux box).

that was unrelated. fixed last night.

 Furthermore, they
 were committed post-beta, which means they should probably have waited
 for after the 3.3 release. So I propose for these commits to be
 reverted.

somebody (?) asked on irc that either Martin or I should update the internal
copies, and someone suggested to do the same with the expat sources. And I asked
our release manager if he was ok with this post beta change.

 (to be clear, I'm talking about all configure / Makefile / setup.py /
 libffi changes since and including
 http://hg.python.org/cpython/rev/e6e99d449bdc876fa57111e7e534c44ecbc3bcbd
 )

the first cross-build fixes went in in April, please consider these fixes for
the then incomplete cros-build fixes. The build issues you did see last night,
were fixed for the OS X build, and I reverted the update for the compiler search
paths for the native build. So please lets keep this cross-build support for
3.3. It's working, tested with a arm-linux-gnueabi build on x86_64-linux-gnu.

  Matthias
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling patches

[Nick Coghlan]

On Sun, Jul 1, 2012 at 6:22 PM, Matthias Klose d...@ubuntu.com wrote:
 the first cross-build fixes went in in April, please consider these fixes for
 the then incomplete cros-build fixes. The build issues you did see last night,
 were fixed for the OS X build, and I reverted the update for the compiler 
 search
 paths for the native build. So please lets keep this cross-build support for
 3.3. It's working, tested with a arm-linux-gnueabi build on x86_64-linux-gnu.

Indeed, especially with the variety of ARM mini-boards coming onto the
market at the moment.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling patches

[Georg Brandl]

On 01.07.2012 10:22, Matthias Klose wrote:

On 30.06.2012 23:17, Antoine Pitrou wrote:


Hello,

I think these patches are premature (they break compilation on OS X,
and they break ctypes configure on my Linux box).


that was unrelated. fixed last night.


It's also something the buildbots can catch easily.


Furthermore, they
were committed post-beta, which means they should probably have waited
for after the 3.3 release. So I propose for these commits to be
reverted.


somebody (?) asked on irc that either Martin or I should update the internal
copies, and someone suggested to do the same with the expat sources. And I asked
our release manager if he was ok with this post beta change.


(to be clear, I'm talking about all configure / Makefile / setup.py /
libffi changes since and including
http://hg.python.org/cpython/rev/e6e99d449bdc876fa57111e7e534c44ecbc3bcbd
)


the first cross-build fixes went in in April, please consider these fixes for
the then incomplete cros-build fixes. The build issues you did see last night,
were fixed for the OS X build, and I reverted the update for the compiler search
paths for the native build. So please lets keep this cross-build support for
3.3. It's working, tested with a arm-linux-gnueabi build on x86_64-linux-gnu.


FWIW, I agree that build fixes for platforms we already support are not a new
feature.  I am not happy about the amount of changes, and I hope that no such
big changes will come until final now...

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling patches

[Antoine Pitrou]

On Sun, 01 Jul 2012 11:37:50 +0200
Georg Brandl g.bra...@gmx.net wrote:
 
  the first cross-build fixes went in in April, please consider these fixes 
  for
  the then incomplete cros-build fixes. The build issues you did see last 
  night,
  were fixed for the OS X build, and I reverted the update for the compiler 
  search
  paths for the native build. So please lets keep this cross-build support for
  3.3. It's working, tested with a arm-linux-gnueabi build on 
  x86_64-linux-gnu.
 
 FWIW, I agree that build fixes for platforms we already support are not a new
 feature.  I am not happy about the amount of changes, and I hope that no such
 big changes will come until final now...

I don't think we have ever supported cross-compiling officially (which
is different from supporting a given platform, e.g. ARM). But fair
enough.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] cross-compiling patches

[Antoine Pitrou]

Hello,

I think these patches are premature (they break compilation on OS X,
and they break ctypes configure on my Linux box). Furthermore, they
were committed post-beta, which means they should probably have waited
for after the 3.3 release. So I propose for these commits to be
reverted.

(to be clear, I'm talking about all configure / Makefile / setup.py /
libffi changes since and including
http://hg.python.org/cpython/rev/e6e99d449bdc876fa57111e7e534c44ecbc3bcbd
)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cross-compiling python and PyQt

[anatoly techtonik]

On Wed, Jun 6, 2012 at 12:35 AM, Terry Reedy tjre...@udel.edu wrote:
 On 6/5/2012 4:24 PM, Tarek Sheasha wrote:

 Hello,
 I have been working for a long time on cross-compiling python for
 android I have used projects like:
 http://code.google.com/p/android-python27/

 I am stuck in a certain area, when I am cross-compiling python I would
 like to install SIP and PyQt4 on the cross-compiled python, I have tried
 all the possible ways I could think of but have had no success. So if
 you can help me by giving me some guidelines on how to install
 third-party software for cross-compiled python for android I would be
 very helpful.


 This is off-topic for pydev list (which is for development *of* Python
 rather than development *with*). I suggest python-list (post in text only,
 please) or other lists for better help.

Yes. And try PySide - it's been ported to distutils, so if distutils
supports cross-compiling you may have better luck there.
--
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Cross-compiling python and PyQt

[Tarek Sheasha]

Hello,
I have been working for a long time on cross-compiling python for android I
have used projects like:
http://code.google.com/p/android-python27/

I am stuck in a certain area, when I am cross-compiling python I would like
to install SIP and PyQt4 on the cross-compiled python, I have tried all the
possible ways I could think of but have had no success. So if you can help
me by giving me some guidelines on how to install third-party software for
cross-compiled python for android I would be very helpful.
Thanks a lot
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cross-compiling python and PyQt

[Terry Reedy]

On 6/5/2012 4:24 PM, Tarek Sheasha wrote:

Hello,
I have been working for a long time on cross-compiling python for
android I have used projects like:
http://code.google.com/p/android-python27/

I am stuck in a certain area, when I am cross-compiling python I would
like to install SIP and PyQt4 on the cross-compiled python, I have tried
all the possible ways I could think of but have had no success. So if
you can help me by giving me some guidelines on how to install
third-party software for cross-compiled python for android I would be
very helpful.


This is off-topic for pydev list (which is for development *of* Python 
rather than development *with*). I suggest python-list (post in text 
only, please) or other lists for better help.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Cross Compiling Python

[Kiran Malla]

Hi All,

I have to cross compile Python to run on Arm processor based MontaVista
Linux.
If anyone has tried this already, please let me know the procedure.

Thanks in advance,

Regards,
Kumar
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cross Compiling Python

[Martin v. Löwis]

 I have to cross compile Python to run on Arm processor based MontaVista 
 Linux.
 If anyone has tried this already, please let me know the procedure.


Dear Kiran,

The python-dev mailing list is for the development *of* Python, not for
the development *with* Python; use python-list@python.org for the
latter. That said, please take a look at the cross-compilation patch
that is currently under review in the patches tracker at 
sf.net/projects/python.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] cross-compiling

[Neal Norwitz]

We've been having some issues and discussions at work about cross
compiling.  There are various people that have tried (are) cross
compiling python.  Right now the support kinda sucks due to a couple
of reasons.

First, distutils is required to build all the modules.  This means
that python must be built twice.  Once for the target machine and once
for the host machine.  The host machine is really not desired since
it's only purpose is to run distutils.  I don't know the history of
why distutils is used.  I haven't had much of an issue with it since
I've never needed to cross compile.  What are the issues with not
requiring python to be built on the host machine (ie, not using
distutils)?

Second, in configure we try to run little programs (AC_TRY_RUN) to
determine what to set.  I don't know of any good alternative but to
force those to be defined manually for cross-compiled environments.
Any suggestions here?  I'm thinking we can skip the the AC_TRY_RUNs
if host != target and we pickup the answers to those from a user
supplied file.

I'm *not* suggesting that normal builds see any change in behaviour.
Nothing will change for most developers.  ie, ./configure ; make ;
./python will continue to work the same.  I only want to make it
possible to cross compile python by building it only on the target
platform.

n

PS.  I would be interested to hear from others who are doing cross
compiling and know more about it than me.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling

[Guido van Rossum]

I know some folks have successfully used cross-compilation before. But
this was in a distant past. There was some support for it in the
configure script; surely you're using that? I believe it lets you
specify defaults for the TRY_RUN macros. But it's probably very
primitive.

About using distutils to build the extensions, this is because some
extensions require quite a bit of logic to determine the build
commands (e.g. look at BSDDB or Tkinter). There was a pre-distutils
way of building extensions using Modules/Setup* but this required
extensive manual editing if tools weren't in the place where they were
expected, and they never were.

I don't have time to look into this further right now, but I hope I
will in the future. Keep me posted!

--Guido

On 11/7/05, Neal Norwitz [EMAIL PROTECTED] wrote:
 We've been having some issues and discussions at work about cross
 compiling.  There are various people that have tried (are) cross
 compiling python.  Right now the support kinda sucks due to a couple
 of reasons.

 First, distutils is required to build all the modules.  This means
 that python must be built twice.  Once for the target machine and once
 for the host machine.  The host machine is really not desired since
 it's only purpose is to run distutils.  I don't know the history of
 why distutils is used.  I haven't had much of an issue with it since
 I've never needed to cross compile.  What are the issues with not
 requiring python to be built on the host machine (ie, not using
 distutils)?

 Second, in configure we try to run little programs (AC_TRY_RUN) to
 determine what to set.  I don't know of any good alternative but to
 force those to be defined manually for cross-compiled environments.
 Any suggestions here?  I'm thinking we can skip the the AC_TRY_RUNs
 if host != target and we pickup the answers to those from a user
 supplied file.

 I'm *not* suggesting that normal builds see any change in behaviour.
 Nothing will change for most developers.  ie, ./configure ; make ;
 ./python will continue to work the same.  I only want to make it
 possible to cross compile python by building it only on the target
 platform.

 n

 PS.  I would be interested to hear from others who are doing cross
 compiling and know more about it than me.
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/guido%40python.org



--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling

[Jeremy Hylton]

On 11/7/05, Guido van Rossum [EMAIL PROTECTED] wrote:
 About using distutils to build the extensions, this is because some
 extensions require quite a bit of logic to determine the build
 commands (e.g. look at BSDDB or Tkinter). There was a pre-distutils
 way of building extensions using Modules/Setup* but this required
 extensive manual editing if tools weren't in the place where they were
 expected, and they never were.

I think part of the problem is that setup.py has a bunch of heuristics
that are intended to do the right thing without user intervention. 
If, on the other hand, the user wants to intervene, because the right
thing is wrong for cross-compiling, you are kind of stuck.  I don't
think there is an obvious way to select the extension modules to build
and the C libraries for them to link against.

Jeremy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling

[Brett Cannon]

On 11/7/05, Neal Norwitz [EMAIL PROTECTED] wrote:
 We've been having some issues and discussions at work about cross
 compiling.  There are various people that have tried (are) cross
 compiling python.  Right now the support kinda sucks due to a couple
 of reasons.

This might make a good sprint topic.  Maybe your employer might be
willing to get some people to come to hack on this?

I know I wouldn't mind seeing the whole build process cleaned up.  It
works well enough, but I think some things could stand to be updated
(speaking from experience of adding EXTRA_CFLAGS to the build
process), such as setup.py being made more modular.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling

[Barry Warsaw]

On Mon, 2005-11-07 at 16:38, Jeremy Hylton wrote:

 I think part of the problem is that setup.py has a bunch of heuristics
 that are intended to do the right thing without user intervention. 
 If, on the other hand, the user wants to intervene, because the right
 thing is wrong for cross-compiling, you are kind of stuck.  I don't
 think there is an obvious way to select the extension modules to build
 and the C libraries for them to link against.

This relates to an issue we've had to workaround with the distutils
based module builds in Python.  For some of the modules, we want the
auto-detection code to find versions of dependent libraries in locations
other than the standard system locations.  I don't think there's a
good way to convince the various setup.py scripts to look elsewhere for
things, short of modifying the code.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling

[Martin v. Löwis]

Neal Norwitz wrote:
 First, distutils is required to build all the modules. 

As Guido already suggests, this assertion is false. In a
cross-compilation environment, I would try to avoid distutils,
and indeed, the build process to do so is still supported.

 Second, in configure we try to run little programs (AC_TRY_RUN) to
 determine what to set.  I don't know of any good alternative but to
 force those to be defined manually for cross-compiled environments.
 Any suggestions here?  I'm thinking we can skip the the AC_TRY_RUNs
 if host != target and we pickup the answers to those from a user
 supplied file.

You shouldn't be required to do that. Instead, just edit pyconfig.h
manually, to match the target. autoconf is designed to support that.

It would help if Makefile was target-independent (only host-dependent).
Not sure whether this is the case.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross-compiling

[Martin v. Löwis]

Jeremy Hylton wrote:
 I think part of the problem is that setup.py has a bunch of heuristics
 that are intended to do the right thing without user intervention. 
 If, on the other hand, the user wants to intervene, because the right
 thing is wrong for cross-compiling, you are kind of stuck.  I don't
 think there is an obvious way to select the extension modules to build
 and the C libraries for them to link against.

Of course there is: Modules/Setup.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] cross compiling python for embedded systems

[giovanniangeli]

is this the right place to ask:
How could I build the python interpreter for an embedded linux target system
(arm9 based), cross-compiling on a linux PC host?

thanks, Giovanni Angeli.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross compiling python for embedded systems

[jepler]

There's a patch on sourceforge for cross compiling.  I haven't used it 
personally.

http://sourceforge.net/tracker/index.php?func=detailaid=1006238group_id=5470atid=305470

Jeff


pgpzVmD49shTu.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cross compiling python for embedded systems

[Martin v. Löwis]

[EMAIL PROTECTED] wrote:
 How could I build the python interpreter for an embedded linux target system
 (arm9 based), cross-compiling on a linux PC host?

No. news:comp.lang.python (aka: mailto:python-list@python.org) would be 
the right list.

This would be the right list for the question I made this and that 
modification to get it cross-compile, can somebody please review them?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com