classification
Title: Endianness and universal builds problems
Type: Stage:
Components: Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, cdavid, loewis, ronaldoussoren
Priority: normal Keywords:

Created on 2008-12-23 03:59 by cdavid, last changed 2008-12-28 19:36 by ronaldoussoren. This issue is now closed.

Files
File name Uploaded Description Edit
smime.p7s ronaldoussoren, 2008-12-28 19:36
Messages (6)
msg78224 - (view) Author: Cournapeau David (cdavid) Date: 2008-12-23 03:59
I had some problems with python and universal builds related to the
WORDS_BIGENDIAN macro. Because universal builds are built in one pass
(one configure), the AC_C_ENDIAN cannot be used reliably. Example:

int main()
{
#ifdef WORDS_BIGENDIAN
    printf("Big endian macro defined\n");
#else
    printf("No big endian macro defined\n");
#endif

    return 0;
}

If I build this against python 2.5, it prints no big endian macro (I
have an intel CPU), as expected. But with python 2.6.0 (official binary
from python.org), I get Big endian macro defined.
msg78228 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-23 09:24
This is related to issue4060. Ronald, what is the status of that?

The only reason why BIGENDIAN could be defined in the official binaries
is that the build was created on a PPC system. Benjamin, is that the case?
msg78234 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-12-23 13:23
Yes, I made the build on a PPC machine. I'm no expert on this, but maybe
we should just get rid of the configure check and use the
__LITTLE_ENDIAN__ and __BIG_ENDIAN__ macros.
msg78247 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-23 19:04
> Yes, I made the build on a PPC machine. 

Hmm. Ronald's instructions say that the build machine must be
x86 for the build to work. I don't know what other
consequences using PPC would have; I recommend that we follow
these instructions until we understand them enough to change
them.

> I'm no expert on this, but maybe
> we should just get rid of the configure check and use the
> __LITTLE_ENDIAN__ and __BIG_ENDIAN__ macros.

That won't work, as not all compilers define these macros.
The 2.5 approach works fine (use the macros on OSX, and
use the configure test elsewhere). Unfortunately, that
support got removed in r63955. The patch in issue4060 looks
fine; I'm unsure why it hasn't been applied yet.
msg78413 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-12-28 15:38
I applied the patch for #4060 in r67982.

I would still like to know what difference an Intel machine makes in the
installers, though.
msg78427 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2008-12-28 19:36
On 28 Dec, 2008, at 16:38, Benjamin Peterson wrote:

>
> Benjamin Peterson <benjamin@python.org> added the comment:
>
> I applied the patch for #4060 in r67982.

I've backported that to 2.6-maint in r67987.
>
>
> I would still like to know what difference an Intel machine makes in  
> the
> installers, though.

It should make no difference at all. I haven't tested building on a  
PPC machine though, all 2.5.x installers were build on an intel box  
because that happens to be my main development machine.  A nice side- 
effect of building on an intel box is that you can test both  
architectures without switching to another machine (through Rosetta).

Ronald
History
Date User Action Args
2008-12-28 19:36:42ronaldoussorensetfiles: + smime.p7s
messages: + msg78427
2008-12-28 15:38:44benjamin.petersonsetstatus: open -> closed
resolution: fixed
messages: + msg78413
2008-12-23 19:04:52loewissetmessages: + msg78247
2008-12-23 13:23:27benjamin.petersonsetmessages: + msg78234
2008-12-23 09:24:39loewissetnosy: + loewis, ronaldoussoren, benjamin.peterson
messages: + msg78228
2008-12-23 03:59:55cdavidcreate