[Buildroot] Python standard library problems

[Pedro Sanchez <psanchez@fosstel.com>]

Thanks Maxime for looking at this. Indeed, my workstation is running 
Linux 64 bits. I'm glad to know that cross-compiling Python goes well on 
a 32-bit OS. I'll have to fire up a VM just to run BR :-|

On the specific problem we have, I don't have any insight yet. All I can 
tell you is that I did the exercise of building BR w/Python using three 
different toolchains (CodeSourcery, Crosstool-ng, and uClibC) and I got 
exactly the same disappointing results**.

Maybe this can help?

http://blog.devork.be/2009/02/compiling-32-bit-python-on-amd64.html

-- 
Pedro

** BTW, uClibC fails to generate the toolchain when the target is arm 
Cortex-A8, just in case you try by chance.



On 08/12/2011 11:44 AM, Maxime Ripard wrote:
> Ok,
>
> A little update on that.
>
>  From my tests, this brokenness occurs only when using a 64-bits system.
> 32 bits systems are fine, which explains why some have a working python
> and other don't.
>
> To complete a bit what I said earlier, in the build log, you have a
> bunch of
> Include/pyport.h:849:2: error: #error "LONG_BIT definition appears wrong
> for platform (bad gcc/glibc config?)."
>
> One for every module that fails to build.
>
> This error comes from the code below in pyport.h
>
> #ifndef LONG_BIT
> #define LONG_BIT (8 * SIZEOF_LONG)
> #endif
>
> #if LONG_BIT != 8 * SIZEOF_LONG
> /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent
>   * 32-bit platforms using gcc.  We try to catch that here at compile-time
>   * rather than waiting for integer multiplication to trigger bogus
>   * overflows.
>   */
> #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
> config?)."
> #endif
>
> LONG_BIT seems correctly defined to 32 in bits/xopen_lim.h of the toolchain.
>
> I'm a bit confused on why this is happening...
>
> On 12/08/2011 12:01, Maxime Ripard wrote:
>> Hi all,
>>
>> With the following config, I have the same problem that Pedro encountered.
>>
>> When you look closer to the build output, when building python, at the
>> end of the process, you have :
>>
>> Failed to build these modules:
>> _bisect            _codecs_iso2022    _collections
>> _csv               _ctypes            _ctypes_test
>> _elementtree       _functools         _heapq
>> _hotshot           _io                _json
>> _locale            _lsprof            _md5
>> _multibytecodec    _multiprocessing   _random
>> _sha               _sha256            _sha512
>> _socket            _struct            _testcapi
>> array              audioop            binascii
>> cmath              cPickle            crypt
>> cStringIO          datetime           dl
>> fcntl              future_builtins    grp
>> imageop            itertools          linuxaudiodev
>> math               mmap               operator
>> ossaudiodev        parser             resource
>> select             spwd               strop
>> syslog             termios            time
>> unicodedata
>>
>> Which is a *lot* of modules. It might be "normal" for some of them, like
>> ossaudiodev which is likely to have an unmet dependency, but note that
>> all three modules Pedro have mentionned are here.
>> Some of them are deprecated too, like imageop.
>>
>> It would be ideal if we could manage to drop the number of failed build
>> modules to 0.
>>
>> I'll try to look into it.
>>
>> Maxime
>>
>
>


-- 
Pedro