python cross compiling

Hi,

In my current project I am integrating the onboard virtual keyboard into ptxdist.
This is my first challenge with ptxdist so my knowledge of ptxdist is not quite good yet.

But I’m stuck on the next issue.

Onboard is compiled through python calling setup.py build.
The .install step uses the CROSS_PYTHON for executing the setup.py.

CROSS_PYTHON = sysroot-cross/bin/python2.6

Setup.py requires python-distultils-extra and python-setuptools which I successfully implemented at
host side.
After the installation of those modules, setup.py continued and printed other requirements.
The next requirements were dconf and GTK+ dependencies which where already implemented at target side.

But when the script tries to get the pkg version it can’t find the dconf or GTK+ package versions.
Those package descriptions are found in the sysroot-target/usr/lib/pkgconfig directory.
But python is looking at sysroot-host for the pkgconfig dir which does not contain the approriate information.

So the script fails and stops because it can’t find the pkgversions.

Is there any documentation or an example of how to redirect python to the target libs?

Kind regards,

		
Bjorn Stuyck

[PATCH] Add option to specify the path to ncurses5-config

By default, gpsd's SConstruct looks in the PATH to find
ncurses5-config. However, in cross-compiling environments, we may need
to tell the SConstruct script to use another ncurses5-config script.

The following implements the equivalent of the
ac_cv_prog_ncurses5_config variable that exists to solve the same
problem in autoconf configure scripts.

The path to the ncurses5-config script can be passed using the
ncurses_config= variable. If no value is passed, the existing behavior
is preserved.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@...>

Index: b/SConstruct
===================================================================
--- a/SConstruct
+++ b/SConstruct
 <at>  <at>  -172,6 +172,7  <at>  <at> 
     ("fixed_stop_bits",     0,             "fixed serial port stop bits"),
     ("target",              "",            "cross-development target"),
     ("sysroot",             "",            "cross-development system root"),
+    ("ncurses_config",      "",            "ncurses5-config path"),
     )
 for (name, default, help) in nonboolopts:
     opts.Add(name, help, default)
 <at>  <at>  -447,6 +448,11  <at>  <at> 
 else:
     pkg_config = lambda pkg: ['!%s --cflags --libs --static %s' %(env['PKG_CONFIG'], pkg, )]

Re: ptxdist-trunk-1329017471 (Main PTXdist Development Trunk) URL-Check vom Sun Feb 12 04:31:11 CET 2012 ()

Dear zlib maintainers,

On Mon, Feb 13, 2012 at 10:18:45AM +0100, Juergen Beisert wrote:
> [...]
> [ FAIL ] http://zlib.net/zlib-1.2.5.tar.bz2

Would it be possible that you leave the old versions at their place,
instead of removing them if a new version is available?

All cross build systems (like ptxdist, OpenEmbedded, yocto, buildroot,
OpenWRT etc) who try to download sources from upstream servers would
really love you for doing this 

rsc
--

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] [PATCH] only include execinfo.h if crashtrace support is enabled

On systems without backtrace suport (E.G. uClibc depending on config),
execinfo.h might not be available, breaking the build.

Fix it by only including it if enabled.

Signed-off-by: Peter Korsgaard <jacmet@...>
---
 src/logging/nm-logging.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/logging/nm-logging.c b/src/logging/nm-logging.c
index ca6a709..26c8670 100644
--- a/src/logging/nm-logging.c
+++ b/src/logging/nm-logging.c
 <at>  <at>  -23,7 +23,6  <at>  <at> 

 #include <dlfcn.h>
 #include <syslog.h>
-#include <execinfo.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
--

-- 
1.7.7.1

beecrypt: Use AC_COMPILE_IFELSE for ICU check for cross compilation compat

AC_RUN_IFELSE doesn't work when cross compiling, but we can do the
check in the preprocessor instead and use AC_COMPILE_IFELSE.

Signed-off-by: Peter Korsgaard <jacmet@...>
---
 configure.ac |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: beecrypt-4.2.1/configure.ac
===================================================================
--- beecrypt-4.2.1.orig/configure.ac
+++ beecrypt-4.2.1/configure.ac
 <at>  <at>  -295,13 +295,13  <at>  <at> 
 if test "$ac_with_cplusplus" = yes; then
   AC_MSG_CHECKING([for IBM's ICU library version >= 2.8])
   AC_LANG_PUSH(C)
-  AC_RUN_IFELSE([
+  AC_COMPILE_IFELSE([
     AC_LANG_PROGRAM([[#include <unicode/uversion.h>]],[[
       #if U_ICU_VERSION_MAJOR_NUM < 2
-      exit(1);
+      #error too old
       #elif U_ICU_VERSION_MAJOR_NUM == 2
       # if U_ICU_VERSION_MINOR_NUM < 8
-      exit(1);
+      #error too old
       # else
       exit(0);
       # endif

beecrypt: Only compile/link cppglue.cxx if --with-cplusplus is used

Bloats libbeecrypt for no use and breaks build on systems without a C++
compiler.

Signed-off-by: Peter Korsgaard <jacmet@...>
---
 Makefile.am |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Index: beecrypt-4.2.1/Makefile.am
===================================================================
--- beecrypt-4.2.1.orig/Makefile.am
+++ beecrypt-4.2.1/Makefile.am
 <at>  <at>  -62,7 +62,12  <at>  <at> 

 lib_LTLIBRARIES = libbeecrypt.la

-libbeecrypt_la_SOURCES = aes.c base64.c beecrypt.c blockmode.c blockpad.c blowfish.c dhies.c
dldp.c dlkp.c dlpk.c dlsvdp-dh.c dsa.c elgamal.c endianness.c entropy.c fips186.c hmac.c hmacmd5.c
hmacsha1.c hmacsha224.c hmacsha256.c md4.c md5.c hmacsha384.c hmacsha512.c memchunk.c mp.c
mpbarrett.c mpnumber.c mpprime.c mtprng.c pkcs1.c pkcs12.c ripemd128.c ripemd160.c ripemd256.c
ripemd320.c rsa.c rsakp.c rsapk.c sha1.c sha224.c sha256.c sha384.c sha512.c sha2k32.c sha2k64.c
timestamp.c cppglue.cxx
+libbeecrypt_la_SOURCES = aes.c base64.c beecrypt.c blockmode.c blockpad.c blowfish.c dhies.c
dldp.c dlkp.c dlpk.c dlsvdp-dh.c dsa.c elgamal.c endianness.c entropy.c fips186.c hmac.c hmacmd5.c
hmacsha1.c hmacsha224.c hmacsha256.c md4.c md5.c hmacsha384.c hmacsha512.c memchunk.c mp.c
mpbarrett.c mpnumber.c mpprime.c mtprng.c pkcs1.c pkcs12.c ripemd128.c ripemd160.c ripemd256.c
ripemd320.c rsa.c rsakp.c rsapk.c sha1.c sha224.c sha256.c sha384.c sha512.c sha2k32.c sha2k64.c timestamp.c
+
+if WITH_CPLUSPLUS
+libbeecrypt_la_SOURCES += cppglue.cxx

ppc32 TEXTREL fix for binutils-2.22

for anyone who targets powerpc, you'll want to make sure to have this fix from 
upstream when using binutils-2.22
-mike

for anyone who targets powerpc, you'll want to make sure to have this fix from 
upstream when using binutils-2.22
-mike

[RFC/PATCH 0/3 v2] fc-cache --root support

The point of these patchsets is to add a --root flag to fc-cache so that
people can build up the font cache in a tree other than /.  This is useful
to people cross-compiling, and for non-root building (chroot won't work).

This ignores the cache file format issue (that's a later patchset).

Mike Frysinger (3):
  FcStrPathPlus: new helper function
  FcStat: export for people to use
  fc-cache: add a --root option

 fc-cache/fc-cache.c     |   59 ++++++++++++++++++++++++++++------------------
 fc-cache/fc-cache.sgml  |   11 ++++++++-
 fontconfig/fontconfig.h |   15 ++++++++++++
 src/fccache.c           |   40 ++++++++++++++++++++++++++++---
 src/fccfg.c             |   59 +++++++++++++++++++++++------------------------
 src/fcdir.c             |   13 ++++++++-
 src/fcfreetype.c        |   10 +++++++-
 src/fcint.h             |    2 +
 src/fcstr.c             |   51 ++++++++++++++++++++++++++++++++++++++++
 src/fcxml.c             |   22 ++++++++++++++++-
 10 files changed, 219 insertions(+), 63 deletions(-)

--

-- 
1.7.6.1

Adding an "easy" and "wip" patch stack

Hi,

A next step we have agreed on is to add two example patch stacks, to
learn about the workflow:

1) an "easy" patch stack where we can quickly agree on
2) a more complicated one, which definitely needs some work.

Suggestions?

rsc

PS: The VM makes progress, but unfortunately we had some hardware issues
    with new RAM on the host server. Our administration team is working
    on this. However, it shouldn't slow down the progress, as we can use
    my git tree posted some days ago in the meantime.
--

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Temporary git repo

Hi,

In order to share the README, I've setup a temporary repository here:
http://git.pengutronix.de/?p=rsc/send-patches-org.git;a=summary

It will move to git.send-patches.org when the machine was set up.

rsc
--

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Proposal for send-patches.org patch repository

About the send-patches.org Patch Repository
-------------------------------------------

This repository contains patches for other open source projects which
are necessary to make them more cross-compiling friendly. The cross
build community has a long history of carrying patches arround, but
trust us - we do all hate them 

Help us make the upstream better and create more awareness for cross
compile issues!

- The send-patches.org team

Patch Guidelines
----------------

The following checklist should make it easier for you to find out if a
patch contains all necessary information:

[ ] Is the patch documented using the Linux kernel's "canonical patch"
    format [1]?

[ ] The patch must contain a subject line (like an email subject),
    stating clearly what the patch does. Example:

    makefile: fix cross compile issues

[ ] Check if the subject line is descriptive enough to understand the
    patch, even if you wouldn't already know what it does :) Add a
    descriptive text to the body if the subject alone isn't enough.