473,326 Members | 2,113 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

distutils & OS X universal binaries

A user reports problems with one of our extensions when running the
intel compiled extension on ppc and vice versa. He is building the
extension as a universal binary. Although the intel compiled version
runs fine it displays a known bug when run on a ppc.

It appears we have an endianness dependency which is statically compiled
into the binaries.

One proposed fix is to make the endian variable code dynamically change
at run time. However, I assume that under the hood the extension is
being built in multiple ways so our static definition of endianness in a
pre-processor macro needs to be dynamic.

Is there a way to get distutils to pass different macros/definitions to
the separate compilations.

Failing that does anyone know off hand exactly how this problem is
supposed to be handled? Ie if there are multiple compiles what
distinguishes them. My understanding is that up to 4 different binaries
are being squashed together in these universal binaries.
--
Robin Becker
Dec 8 '07 #1
14 1635
One proposed fix is to make the endian variable code dynamically change
at run time.
I would advise against that. Endianness depdency should be resolved at
compile time, with appropriate conditional compilation. Endianness won't
change at run-time (and no, not even for a fat binary - the x86 code
will always "see" the same endianness, and so will the ppc code).
Is there a way to get distutils to pass different macros/definitions to
the separate compilations.
No. distutils only invokes the compiler a single time, not multiple
times, for a specific universal object file. The gcc driver then invokes
different cc1 backends repeatedly.
Failing that does anyone know off hand exactly how this problem is
supposed to be handled? Ie if there are multiple compiles what
distinguishes them. My understanding is that up to 4 different binaries
are being squashed together in these universal binaries.
In the specific case, just use the WORDS_BIGENDIAN macro defined in
pyconfig.h; it will be defined if the target is bigendian, and
undefined otherwise. In the case of a universal build, it will be
undefined in the x86 compiler invocation, and defined in the ppc
invocation.

If you are curious as to how it arranges that, read the source.

Regards,
Martin
Dec 8 '07 #2
Robin Becker wrote:
A user reports problems with one of our extensions when running the
intel compiled extension on ppc and vice versa. He is building the
extension as a universal binary. Although the intel compiled version
runs fine it displays a known bug when run on a ppc.
Have you reported the problem at http://bugs.python.org/? A minimal
example could help us to fix the problem.

Christian

Dec 8 '07 #3
>A user reports problems with one of our extensions when running the
>intel compiled extension on ppc and vice versa. He is building the
extension as a universal binary. Although the intel compiled version
runs fine it displays a known bug when run on a ppc.

Have you reported the problem at http://bugs.python.org/? A minimal
example could help us to fix the problem.
At first, I also thought that Robin suggested that there is a problem
with Python. Upon re-reading, I now believe he rather sees the bug
in the reportlabs code, and is asking for an approach to solve it there.

Regards,
Martin
Dec 8 '07 #4
Martin v. Löwis wrote:
>>A user reports problems with one of our extensions when running the
intel compiled extension on ppc and vice versa. He is building the
extension as a universal binary. Although the intel compiled version
runs fine it displays a known bug when run on a ppc.
Have you reported the problem at http://bugs.python.org/? A minimal
example could help us to fix the problem.

At first, I also thought that Robin suggested that there is a problem
with Python. Upon re-reading, I now believe he rather sees the bug
in the reportlabs code, and is asking for an approach to solve it there.
.....
Yes that's right. Unfortunately this problem doesn't arise in the python
interface, but in libart_lgpl which we depend on. I will look at the
pyconfig.h code to see how our definition should be put into libart's .h
config file. Presumably I can then remove the calculated definition we
have in our setup.py script or at least override it in the right way.

PIL may also have a similar problem as the 1.1.6 setup.py script also
defines WORDS_BIGENDIAN like this

if struct.unpack("h", "\0\1")[0] == 1:
defs.append(("WORDS_BIGENDIAN", None))

probably I borrowed/stole this as we have something very similar in our
setup.py.
--
Robin Becker
Dec 8 '07 #5
Martin v. Löwis wrote:
At first, I also thought that Robin suggested that there is a problem
with Python. Upon re-reading, I now believe he rather sees the bug
in the reportlabs code, and is asking for an approach to solve it there.
I saw your posting after I sent mine. The gmane web interface is slow
and sluggish today.

The macro WORDS_BIGENDIAN isn't mentioned in the docs. The docs sure
need some extra information how to create universal binaries and how to
write endian safe C code. I'm going to create a GHOP task.

Christian

Dec 8 '07 #6
Martin v. Löwis wrote:
..........
>
In the specific case, just use the WORDS_BIGENDIAN macro defined in
pyconfig.h; it will be defined if the target is bigendian, and
undefined otherwise. In the case of a universal build, it will be
undefined in the x86 compiler invocation, and defined in the ppc
invocation.

If you are curious as to how it arranges that, read the source.
.......

OK I read the source and am slightly puzzled by the code in
pyconfig.h.in which reads

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif
I'm puzzled why WORDS_BIGENDIAN is undefined if both __BIG_ENDIAN__ and
__LITTLE_ENDIAN__ are undefined. Surely in that case WORDS_BIGENDIAN
should be left alone (if it is already defined). If there's a compiler
for a bigendian architecture which doesn't define the gcc macros the we
seem to get the wrong result.
--
Robin Becker
Dec 8 '07 #7
#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif
I'm puzzled why WORDS_BIGENDIAN is undefined if both __BIG_ENDIAN__ and
__LITTLE_ENDIAN__ are undefined. Surely in that case WORDS_BIGENDIAN
should be left alone (if it is already defined). If there's a compiler
for a bigendian architecture which doesn't define the gcc macros the we
seem to get the wrong result.
No. pyconfig.h.in gets processed by configure into pyconfig.h; configure
replaces all #undef lines with appropriate #define lines if the macro
got define in configure. The autoconf macro AC_C_BIGENDIAN performs
a configure-time check. So

- if the compiler either defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__,
that is taken for granted.
- otherwise, the configure-time value is used

On your normal big-endian compiler (e.g. SPARC), it's the
configure-time value that makes WORDS_BIGENDIAN defined.

HTH,
Martin
Dec 8 '07 #8
PIL may also have a similar problem as the 1.1.6 setup.py script also
defines WORDS_BIGENDIAN like this

if struct.unpack("h", "\0\1")[0] == 1:
defs.append(("WORDS_BIGENDIAN", None))

probably I borrowed/stole this as we have something very similar in our
setup.py.
All such checks are broken for fat binaries. Fat binaries essentially
are a form of cross-compilation, and in cross-compilation, thou shalt
not infer target system properties by looking at the host system.

(IOW, autoconf is, in principle, also broken for fat binaries. Indeed,
although the current solution for WORDS_BIGENDIAN is good for ppc
vs. x86, many of the other configure-time detected properties are
incorrect for ppc vs. ppc64 or x86 vs. amd64, such as SIZEOF_LONG)

Regards,
Martin
Dec 8 '07 #9
Martin v. Löwis wrote:
........
>I'm puzzled why WORDS_BIGENDIAN is undefined if both __BIG_ENDIAN__ and
__LITTLE_ENDIAN__ are undefined. Surely in that case WORDS_BIGENDIAN
should be left alone (if it is already defined). If there's a compiler
for a bigendian architecture which doesn't define the gcc macros the we
seem to get the wrong result.

No. pyconfig.h.in gets processed by configure into pyconfig.h; configure
replaces all #undef lines with appropriate #define lines if the macro
got define in configure. The autoconf macro AC_C_BIGENDIAN performs
a configure-time check. So
>
- if the compiler either defines __BIG_ENDIAN__ or __LITTLE_ENDIAN__,
that is taken for granted.
- otherwise, the configure-time value is used

On your normal big-endian compiler (e.g. SPARC), it's the
configure-time value that makes WORDS_BIGENDIAN defined.
.......

OK I need to use something a bit more complex then; I figure this should
work

#if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)
# ifdef __BIG_ENDIAN__
# ifdef WORDS_BIGENDIAN
# undef WORDS_BIGENDIAN
# endif
# define WORDS_BIGENDIAN 1
# else
# ifdef __LITTLE_ENDIAN__
# ifdef WORDS_BIGENDIAN
# undef WORDS_BIGENDIAN
# endif
# endif
# endif
#endif
--
Robin Becker
Dec 8 '07 #10
OK I need to use something a bit more complex then; I figure this should
work

#if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)
# ifdef __BIG_ENDIAN__
# ifdef WORDS_BIGENDIAN
# undef WORDS_BIGENDIAN
# endif
# define WORDS_BIGENDIAN 1
# else
# ifdef __LITTLE_ENDIAN__
# ifdef WORDS_BIGENDIAN
# undef WORDS_BIGENDIAN
# endif
# endif
# endif
#endif
I don't understand. If you assume that either __BIG_ENDIAN__ or
__LITTLE_ENDIAN__ is defined, anyway - just use that!

If neither is defined, you are still lost, unless you use pyconfig.h,
in which case, you don't need anything of that.

Regards,
Martin
Dec 8 '07 #11
Martin v. Löwis wrote:
>OK I need to use something a bit more complex then; I figure this should
work

#if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)
# ifdef __BIG_ENDIAN__
# ifdef WORDS_BIGENDIAN
.........
>#endif

I don't understand. If you assume that either __BIG_ENDIAN__ or
__LITTLE_ENDIAN__ is defined, anyway - just use that!

If neither is defined, you are still lost, unless you use pyconfig.h,
in which case, you don't need anything of that.
I prefer to continue using WORDS_BIGENDIAN so fewer changes need to be
made to the code. It just makes resynching with the upstream code
easier. If neither are defined we get to use the definition from
setup.py if it's needed.
--
Robin Becker
Dec 8 '07 #12
I prefer to continue using WORDS_BIGENDIAN so fewer changes need to be
made to the code. It just makes resynching with the upstream code
easier. If neither are defined we get to use the definition from
setup.py if it's needed.

Ok. Still, I would write it as

#if defined(__LITTLE_ENDIAN__)
#undef WORDS_BIGENDIAN
#elif defined(__BIG_ENDIAN__)
#undef WORDS_BIGENDIAN
#define WORDS_BIGENDIAN 1
#endif

Regards,
Martin
Dec 9 '07 #13
Martin v. Löwis wrote:
>I prefer to continue using WORDS_BIGENDIAN so fewer changes need to be
made to the code. It just makes resynching with the upstream code
easier. If neither are defined we get to use the definition from
setup.py if it's needed.


Ok. Still, I would write it as

#if defined(__LITTLE_ENDIAN__)
#undef WORDS_BIGENDIAN
#elif defined(__BIG_ENDIAN__)
#undef WORDS_BIGENDIAN
#define WORDS_BIGENDIAN 1
#endif

Regards,
Martin
I'm never sure if undef gives an error if the variable isn't defined,
but that is cleaner

thanks for the assistance
--
Robin Becker
Dec 9 '07 #14
Robin Becker wrote:
.........
>Ok. Still, I would write it as

#if defined(__LITTLE_ENDIAN__)
#undef WORDS_BIGENDIAN
#elif defined(__BIG_ENDIAN__)
#undef WORDS_BIGENDIAN
#define WORDS_BIGENDIAN 1
#endif

Regards,
Martin
I'm never sure if undef gives an error if the variable isn't defined,
but that is cleaner

thanks for the assistance
Just like to say my testee/victim reports great success with the above snippet
inserted into the right config file. Thanks to all.
--
Robin Becker

Dec 10 '07 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Isaac Jones | last post by:
Hello Python Community. I bring greetings from the Haskell community (http://www.haskell.org) ;) There has been a lot of discussion of late about creating a grand-unified build & distribution...
0
by: Phil Hornby | last post by:
I have tried posting this to the distutils SIG list but had no response so I am hoping the general list can help... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Okay, I love what I can do with...
1
by: Mathieu Malaterre | last post by:
Hello, I thought this would be easy but I guess I didn't get the distutil feeling. I am trying to write a setup for install my package but I don't understand how to do that. organisation: ...
15
by: Colin J. Williams | last post by:
The distutils download page has: -------------------------------------------------------- Current stable release The current stable release is Distutils 1.0.2; you can download it as: *...
1
by: Terry Hancock | last post by:
Some time ago, I got the idea that I wanted to build image resources from vector graphic originals, instead of marshalling hundreds of tiny little icon images by hand. I wrote "BuildImage" to do...
0
by: Maarten Sneep | last post by:
I'm trying to build PyBison on Mac OS X, and I'm running into some problems with the distutils. Just for starters: PyBison requires Pyrex. This is not a problem, and Pyrex seems to work without...
72
by: Paminu | last post by:
In math this expression: (a < b) && (b < c) would be described as: a < b < c But why is it that in C these two expressions evaluate to something different for the same values of a, b and...
9
by: seberino | last post by:
I have been using distuils for a while and was wondering when Python Eggs (new project) is better? So basically Python Eggs precompiles and compresses binaries for you so you just have to load...
10
by: Immortalist | last post by:
Various aquisition devices that guide learning along particular pathways towards human biases. And as E.O. Wilson might say mental development appears to be genetically constrained. (1) Language...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.