Mailing List Archive: Python: Bugs

[issue1006238] cross compile patch

Index | Next | Previous | View Threaded

report at bugs

Oct 31, 2009, 3:53 PM

Post #1 of 10 (378 views)
Permalink

[issue1006238] cross compile patch

Garrett Cooper <yanegomi [at] gmail> added the comment:

I'm trying to resolve this issue on:

2.6-releasemaint
trunk
3.1-releasemaint
py3k

first by resolving issues configure.in, but there are a TON of
AC_TRY_RUN's, which means that this code cannot be cross-compiled as-is
(25 on 2.x -- 27 on 3.x).

Is requiring the end-user to define the autoconf variables appropriately
to their platform when running configure (when provided an error message
telling them so), a longterm sustainable requirement? I know it isn't as
user friendly, but this is a definite problem that either needs to be
fixed in the autoconf tests (if possible) or the C code itself.

I wouldn't mind updating the INSTALL or README files to reflect this
change either, if needed.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 31, 2009, 4:14 PM

Post #2 of 10 (363 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Gregory P. Smith <greg [at] krypto> added the comment:

Documenting the parameters needed to avoid all AC_TRY_RUNs is a good first
step for any that are not obvious how to convert from AC_TRY_RUN into
something else.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 4:50 AM

Post #3 of 10 (339 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Mike Frysinger <vapier [at] users> added the comment:

AC_TRY_RUN is already documented:
http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992

there are a bunch of distros out there (like OE and Gentoo) that have
been maintaining cross-compile patches for python. i'm pretty sure the
stuff in Gentoo works for 2.6.x, but i havent tried 3.1.x yet.

ive given up on pushing to upstream as this bug (among others)) shows
that such attempts go nowhere

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 9:35 AM

Post #4 of 10 (339 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Gregory P. Smith <greg [at] krypto> added the comment:

Removing a toxic person from the cc list. Mike, please go harm some other
all volunteer project.

----------
nosy: -vapier

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 11:55 AM

Post #5 of 10 (339 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Garrett Cooper <yanegomi [at] gmail> added the comment:

On Sun, Nov 1, 2009 at 5:50 AM, Mike Frysinger <report [at] bugs> wrote:
>
> Mike Frysinger <vapier [at] users> added the comment:
>
> AC_TRY_RUN is already documented:
> http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992
>
> there are a bunch of distros out there (like OE and Gentoo) that have
> been maintaining cross-compile patches for python. i'm pretty sure the
> stuff in Gentoo works for 2.6.x, but i havent tried 3.1.x yet.
>
> ive given up on pushing to upstream as this bug (among others)) shows
> that such attempts go nowhere

Actually what Mike showed was helpful for me. I didn't realize that
the 3rd argument to AC_TRY_RUN was for Canadian cross, aka
cross-compiling.

My personal opinion on why past attempts have failed (and it's just my
opinion) is probably because:

1. The change set wasn't incremental, thus the diff was large, and the
checkin was rejected.
2. The patch was based on previous versions of python, which doesn't
help the current trunk, release-maint* branches, etc.

I'm more than happy to steal existing code (if possible :)..), but it
should be well designed so longterm maintenance can be eased, and the
cross-compile issue can be resolved in a correct manner.

It took me 2 months to rewrite the Makefile infrastructure for LTP --
this should be a lot simpler and less painful to resolve (in terms of
autotools input files, Makefile, etc). setup.py and distutils is
something that I need to defer to someone more seasoned in the python
internals (at least for mentoring) s.t. it can be resolved on all
branches.

First comes first, I'll propose some changes for cross-compilation
dealing with some of the AC_TRY_RUN tests -- there are some tests that
can be turned into preprocessor defines and/or AC_TRY_COMPILES [the
sizeof(pthread_t), etc], then I'll look at the other tests and propose
appropriate action for them.

If needed individuals in the python org. aren't aware of this work, it
probably should be brought to their attention sometime in the next
couple of weeks, because I need to make sure core team members are
aware of these changes so that they can get reviewed and checked into
the project in a timely manner (my group needs to upgrade from 2.4.2
to python 2.6.x in the next couple months; this is a stopgap item for
us because we use a cross-compilation environment).

All the best,
-Garrett

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 12:57 PM

Post #6 of 10 (335 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Mike Frysinger <vapier [at] users> added the comment:

Gregory: there's no need to be a dick. i'm pointing out the obvious --
bugs have been open literally for *years* with zero assistance/feedback
from anyone who can actually get things merged. people have posted
patches, but no one has said "xxx needs to be done in order to get
merged". you havent posted anything here either (assuming you're
someone who can actually get things merged and not just comment in a
tracker). if you can at least do something with trackers, you should
start by marking 1597850 as a dupe of this one. or you can simply prove
my point by continuing to contribute nothing.

the basic required changes are simple -- fix the few autoconf tests.
getting automatic cross-detection (building a host python/pygen
automatically) isnt nearly as important as long as people have a way to
tell the build system to use a different python/pgen for build purposes.
last i looked, these simple changes were pretty trivial to move across
major versions of python.

i fixed the chflags specific check a long time ago (as i imagine others
have as well):
http://sources.gentoo.org/dev-lang/python/files/python-2.6-chflags-cross.patch

same goes for the printf %zd test:
http://sources.gentoo.org/dev-lang/python/files/python-2.5-cross-printf.patch

however, unless these trivial baby steps can be made, worrying about the
next step (properly cross-compiling modules and such) is a complete
waste of time as these require diving into the python-specific build
system which does see a lot of churn over versions.

----------
nosy: +vapier

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 3:20 PM

Post #7 of 10 (345 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Garrett Cooper <yanegomi [at] gmail> added the comment:

Ok. Taking a look at trunk...

The following could be converted to AC_TRY_COMPILE statements for the
3rd AC_TRY_RUN tuple:

1. $ac_enable_profiling : 697
2. $ac_cv_no_strict_aliasing_ok : 921
3. $ac_cv_opt_olimit_ok : 1070
4. $ac_cv_olimit_ok : 1092
5. $ac_cv_pthread_is_default : 1126
6. $ac_cv_kpthread : 1163
7. $ac_cv_pthread : 1225
8. $ac_osx_32bit : 1569
9. $ac_cv_pthread_system_supported : 2229
10. $ac_cv_have_size_t_format : 3959

The following can just be converted to AC_TRY_COMPILE:
1. $ipv6 : 2278
2. $ac_cv_have_chflags : 2663
3. $ac_cv_have_lchflags : 2693

The following will need to be sorted out, as to what needs to be done
here, as they are legitimate runtime only tests:
1. $ac_cv_little_endian_double : 3249
2. $ac_cv_big_endian_double : 3271
3. $ac_cv_mixed_endian_double : 3299
4. $ac_cv_x87_double_rounding : 3354
5. $ac_cv_broken_sem_getvalue : 3395
6. $ac_cv_tanh_preserves_zero_sign : 3430
7. $ac_cv_wchar_t_signed : 3510
8. $ac_cv_rshift_extends_sign : 3597
9. $ac_cv_broken_nice : 3714
10. $ac_cv_broken_poll : 3735
11. $ac_cv_working_tzset : 3772

Taking a look at py3k, most of the offsets are the same -- some have
changed, but the only the test which doesn't exist in trunk is the
following:

1. $ac_cv_broken_mbstowcs : 3872

Again, this is a valid runtime test, so it needs to be sorted out what
should be done here with cross-compilation.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 6:03 PM

Post #8 of 10 (344 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Gregory P. Smith <greg [at] krypto> added the comment:

these two have been merged and applied to trunk.

"""
i fixed the chflags specific check a long time ago (as i imagine others
have as well):
http://sources.gentoo.org/dev-lang/python/files/python-2.6-chflags-
cross.patch

same goes for the printf %zd test:
http://sources.gentoo.org/dev-lang/python/files/python-2.5-cross-
printf.patch
"""

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 7:20 PM

Post #9 of 10 (343 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Mike Frysinger <vapier [at] users> added the comment:

the chflags is specifically documented as needing a runtime test:
# On Tru64, chflags seems to be present, but calling it will
# exit Python

which is why i left the default of AC_TRY_RUN but cross-compile falls
back to a simple link test. btw, a compile test is not valid when
trying to see if a function exists. you'll get a successful compile
(and warning about implicit function), but no error because you didnt
finally link the object with the undefined reference.

somewhat similar are the compiler checks (profile/pthread/alias/etc...).
some compilers do different things when linking and compiling (like gcc
and -pthread), so sticking to a LINK in the fallback of the RUN is
better, although not always perfect. some flags are accepted/ignored by
compilers and issue only warnings about the unknown flags, not errors.
but this issue probably isnt worth worrying about considering the code
in there today suffers from this edge case (and if no one is
complaining, then forget about it).

in terms of making sure all AC_TRY_RUN's have cross-compile fallbacks, i
only worried about the ones that actually get exercised. the two i
posted fixes for are the only ones ive seen people (and myself) actively
hit.

the ipv6 should def have a LINK fallback, and it should try using
in6addr_any as that is often an exported symbol (which is missing when
ipv6 doesnt exist).

the double endian checks could easily be made into a compile test with a
creative grep. pick a double value that expands into a funky ascii
string and then grep the object file for a match. otherwise, a char
swapped ascii string indicates it's big endian.

the wchar/rshift signed tests can be made into a compile-only test by
creative use of arrays (like autoconf does now with compile sizeof() tests).
main() { char foo[(((wchar_t) -1) < ((wchar_t) 0)) ? 1 : -1]; }
compilers will portably abort when array size is negative, and this
expression should be a constant.

i dont think any of the "broken" ones need to be sorted out as they
already have cross-compile fall backs and there isnt much to be done in
figuring out if the run time env is broken.

thanks Greg for the commits !

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 10:22 PM

Post #10 of 10 (331 views)
Permalink

[issue1006238] cross compile patch [In reply to]

Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA [at] GMail>:

----------
nosy: +Arfrever

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads