Building Python extensions

Building Python extensions

[Marcin Juszkiewicz]

Thanks to Mickeyl's work we have nice support for building Python and 
Python related stuff in OpenEmbedded.

Recently I was working for OpenedHand on project which required lot of 
Python work to get stuff done. And I got hit by lot of problems due to 
64bit host environment while I was building for 32bit target. In short: 
it is miracle that Python stuff was building before...

Longer version:

When we build Python extension (for example python-pygtk2) configure 
script builds one test program to check does it has Python headers. On my 
system it mostly failed due to this part of python2.4/pyport.h header:

#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

And all because wrong include path is used:

configure:9284: checking for headers required to compile python extensions
configure:9303: arm-linux-gcc -E 
-isystem/a/home/hrw/devel/build/cel/tmp/staging/arm-linux/include 
-I/a/home/hrw/devel/build/cel/tmp/staging/i686-linux/include/python2.4 
conftest.c

So as long as we are building for target of same size as host (32bit for 
32bit) everything is ok but everything is going to break for 64bit -> 
32bit (or vice versa).

I got fix for it of course. M4 scripts of each used Python extensions use 
macro AM_CHECK_PYTHON_HEADERS which I edited to add one option to 
configure: --with-python-includes which should be pointed to 
${STAGING_INCDIR}/../ to get it working.

I will sync some of Python extensions with this fix from Poky into 
OpenEmbedded in next days (python-pygtk2 already pushed).

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

           Q:      What's a light-year?
           A:      One-third less calories than a regular year.

Re: Building Python extensions

[Dr. Michael Lauer]

(Sorry for the long delay... :)

Marcin Juszkiewicz wrote on 23th of March:
> When we build Python extension (for example python-pygtk2) configure
> script builds one test program to check does it has Python headers.

So this is a problem with python packages using autotools only, right?
(I remember I patched distutils to take care about that).

> I got fix for it of course. M4 scripts of each used Python extensions use
> macro AM_CHECK_PYTHON_HEADERS which I edited to add one option to 
> configure: --with-python-includes which should be pointed to 
> ${STAGING_INCDIR}/../ to get it working.

So just adding to EXTRA_OECONF will do?

> I will sync some of Python extensions with this fix from Poky into 
> OpenEmbedded in next days (python-pygtk2 already pushed).

Since we don't have that many extensions using autotools, we can fix
this easily.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Building Python extensions

[Marcin Juszkiewicz]

Dnia środa, 22 sierpnia 2007, Dr. Michael Lauer napisał:
> Marcin Juszkiewicz wrote on 23th of March:
> > When we build Python extension (for example python-pygtk2) configure
> > script builds one test program to check does it has Python headers.

> So this is a problem with python packages using autotools only, right?
> (I remember I patched distutils to take care about that).

looks like it

> > I got fix for it of course. M4 scripts of each used Python extensions
> > use macro AM_CHECK_PYTHON_HEADERS which I edited to add one option to
> > configure: --with-python-includes which should be pointed to
> > ${STAGING_INCDIR}/../ to get it working.
>
> So just adding to EXTRA_OECONF will do?

Need to patch acinclude.m4 too.

> > I will sync some of Python extensions with this fix from Poky into
> > OpenEmbedded in next days (python-pygtk2 already pushed).
>
> Since we don't have that many extensions using autotools, we can fix
> this easily.

you or me?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

        Linux! -- Because a big world can not fit in small windows.

Re: Building Python extensions

[Dr. Michael Lauer]

Marcin Juszkiewicz wrote:
>> > I will sync some of Python extensions with this fix from Poky into
>> > OpenEmbedded in next days (python-pygtk2 already pushed).
>>
>> Since we don't have that many extensions using autotools, we can fix
>> this easily.

> you or me?

If you have time, please take a shot. I'm on Froscon07 and on MDD07 and won't
have time before returning from Denmark (early September).

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Building Python extensions

[Davis, Scott (AGRE)]

I am trying to build a 32-bit shared library for a C library I have on
an x86_64 AMD SuSE linux system.  I am observing the same problem that
apparently someone on your list has had.  I have a commercial C 32-bit
linux library that I want to use SWIG to build a python extension for.
My linux system is 64-bit and when I compile against Python.h for Python
2.4 I get #error LONG BIT below emitted. 

The original post is at the URL below:
http://projects.linuxtogo.org/pipermail/openembedded-devel/2007-March/00
1722.html

What is the fix to build 32-bit shared library python extension on a
64-bit linux system?

#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 

Scott Davis
GE
Aviation
Digital Systems
Principal Software Engineer

T 616 224 6659
F 616 241 8707
E scott.davis@smiths-aerospace.com
www.ge.com/aviation 

3290 Patterson Ave, SE 
Grand Rapids, MI 49512, U.S.A.



</table> </Pre>
<HTML>
<br>
<br>
************************************************<br>
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.<br>
************************************************<br>
</HTML>
From openembedded@hrw.one.pl Thu May 24 14:05:18 2007
Received: from [195.149.226.213] (helo