This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sergiodj
Recipients bobatkins, loewis, sergiodj
Date 2008-04-15.13:01:41
SpamBayes Score 0.000545907
Marked as misclassified No
Message-id <1208264514.5817.3.camel@miki>
In-reply-to <4803B8E6.7000905@v.loewis.de>
Content
Hi Martin,

On Mon, 2008-04-14 at 20:04 +0000, Martin v. Löwis wrote:
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
> > This is what you get when you try to build a 64-bit Python on a biarch
> > machine (64-bit kernel, 32-bit userspace), using a gcc that generates
> > natively 32-bit objects (therefore, you *must* pass the '-m64' option
> > for the compiler):
> 
> Or you install an additional, different, C compiler that defaults to
> AMD64.

I cannot do that. Actually, even if I could, I don't think this is the
best way to handle this *Python*'s problem.

> > 1) As you could see above, actually you need CFLAGS in order to compile
> > Python correctly. As far as I could investigate, the reason you need
> > this is because of the tests that are done by configure. Without the
> > CFLAGS, configure will think it's building a 32-bit Python, despite of
> > the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
> > through Makefile or not? IMHO, we do.
> 
> Not necessarily. I think you can achieve the same effect by specifying
> CC="gcc -m64" to configure.

I know that. But the purpose of CC flag is to define a compiler to be
used in the compilation, and not to specify compiler flags (for that, we
have CFLAGS).

> > Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
> > But again, I don't think this is a solution for this issue :-).
> 
> Why not?

See above.

Regards,
History
Date User Action Args
2008-04-15 13:01:44sergiodjsetspambayes_score: 0.000545907 -> 0.000545907
recipients: + sergiodj, loewis, bobatkins
2008-04-15 13:01:42sergiodjlinkissue1628484 messages
2008-04-15 13:01:41sergiodjcreate