All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Sanchez <psanchez@fosstel.com>
To: buildroot@busybox.net
Subject: [Buildroot] Python standard library problems
Date: Tue, 30 Aug 2011 10:36:18 -0400	[thread overview]
Message-ID: <4E5CF562.6070800@fosstel.com> (raw)
In-Reply-To: <4E5BB725.9030408@free-electrons.com>

Thanks for the patch. I think it's been tested since I see it's 
committed already. But I'll give a try anyway and will let you know.

Thanks!,

-- 
Pedro
On 08/29/2011 11:58 AM, Maxime Ripard wrote:
> Hi Pedro,
>
> I've just sent a patch for this issue, could you test it ?
>
> Maxime
>
> On 16/08/2011 10:22, Maxime Ripard wrote:
>> Hi,
>>
>> On 12/08/2011 19:47, Pedro Sanchez wrote:
>>> 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 :-|
>>
>> Or maybe we can just fix this bug :)
>>
>>> 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**.
>>
>> Neither am I. I don't get why a cross-toolchain which runs fine could
>> fail to build a specific module. After all, on 32 and 64 bits, we use
>> the exact same toolchains (at least for the Code Sourcery one.).
>>
>> After all, the host-python should be compiled for 64 bits using the
>> native toolchain, and the target one compiled (in our case at least) for
>> 32 bits, with the cross-toolchain. There shouldn't be any 64-to-32 bits
>> compilation at all.
>>
>>> Maybe this can help?
>>>
>>> http://blog.devork.be/2009/02/compiling-32-bit-python-on-amd64.html
>>
>> Yep, I ran into that trick last week too. I'm not sure this is a good
>> one though. This is a good quick fix, but I wonder what will happen if
>> your target is a 64bits architecture ? Moreover, this adds the
>> dependency to gcc-multilib.
>>
>> Peter, what do you think of it ?
>>
>> Maxime
>>
>
>


-- 
Pedro

  reply	other threads:[~2011-08-30 14:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 19:18 [Buildroot] Python standard library problems Pedro Sanchez
2011-08-10 21:48 ` Dominic Newton
2011-08-11 13:14   ` Pedro Sanchez
2011-08-11 15:37     ` Dominic Newton
2011-08-11 18:23       ` Pedro Sanchez
2011-08-11 20:54         ` Pedro Sanchez
2011-08-12 10:01           ` Maxime Ripard
2011-08-12 15:44             ` Maxime Ripard
2011-08-12 17:47               ` Pedro Sanchez
2011-08-16  8:22                 ` Maxime Ripard
2011-08-29 15:58                   ` Maxime Ripard
2011-08-30 14:36                     ` Pedro Sanchez [this message]
2011-08-31 14:17                       ` Pedro Sanchez
2011-09-01  7:50                         ` Thomas Petazzoni
2011-09-01 14:18                           ` Pedro Sanchez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E5CF562.6070800@fosstel.com \
    --to=psanchez@fosstel.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.