gmane.linux.distributions.ltib.general

Build results for 20130517

autobuilder — 2013-05-19T14:31:05

Build results for 20130517

autobuilder — 2013-05-17T19:08:36

Re: Host python patch

Stuart Hughes — 2013-05-17T15:39:13

Hi Mike,

Sounds good to me.  Free free to add this, but not to the default list
in config/platform/host/ltib.prefconfig.

Usually, most .spec files should work whether for the host or a target
board (that's the aim).  There are a few exceptions (such as rpm-fs) though.

I've read this at speed, so forgive me if I've missed anything.

Regards, Stuart

On 14/05/13 01:44, Mike Goins wrote:

Build results for 20130516

autobuilder — 2013-05-16T19:19:30

Build results for 20130515

autobuilder — 2013-05-15T19:16:10

Build results for 20130514

autobuilder — 2013-05-14T18:40:06

Re: Host python patch

Mike Goins — 2013-05-14T00:44:52

Thanks for the clarification.  I am pretty confident that the host
python is pretty vanilla and does not depend on any target
configuration, hence the result was to carve it out to it's own spec
file.

I have more patches that ride on top of this as hinted in the previous
message, mod_python, wsgi, libxml bindings, etc.  They have all worked
out very well, and have our production software using these.

I could even mange a bump to v2.6 if there is enough of a desire.

Build results for 20130513

autobuilder — 2013-05-13T19:43:41

Re: Host python patch

Stuart Hughes — 2013-05-13T17:55:53

Hi Mike,

In general the packages installed into /opt/ltib/usr/bin are regular and
can be see as extensions to the host system.

If you're building something that runs on the host, but is sensitive to
the platform/toolchain etc then in the past it's been put into
$PROJECT_DIR/bin/...  For example the host gdb that is built is put
there as it would be different depending on whether you're building ARM,
PowerPC etc (and indeed the particular toolchain).

So if the host-python could only really be built one way, then it is
okay to put it into the /opt/ltib/... bucket.  Otherwise maybe it's
better under bin (in the ltib project you're building).

Regards, Stuart


On 13/05/13 11:41, Mike Goins wrote:

Host python patch

Mike Goins — 2013-05-13T10:41:18

The existing python.spec file builds a localized version of python to
do the cross-compile, then it is tossed.  This works just fine, but
other packages could use or need a "host" python that matches the
cross-built: mod_wsgi, libxml python bindings, mod_python.  Using the
native python installation to build these poses problems, particularly
64-bit hosts.

python-host-enable.patch:
1. Adds a python-host.spec file that builds and installs a 32 bit
version of python for the host.
2. python.spec updated to detect whether host python is installed and
uses it, else it maintains the current behavior.

python-2.4.4-linux3.patch.
This is only incidental to the issue, but included since I have not
uploaded this to the GPP.  This enables python builds on Linux 3.x
systems.  Fairly trivial.

Feedback welcomed, as there are operations that I am not sure if good
practices, like

#test if there is ltib installed python
if [ ! -e $DEFPFX/usr/bin/python ]; then

I wasn't sure if there was a better way than just check if it

Build results for 20130510

autobuilder — 2013-05-10T18:39:45

Re: ltib host libs vs x86 platform

Stuart Hughes — 2013-05-09T18:56:01

Hi Mike,

Unfortunately in this case /opt/ltib is deliberately making use of the
system area (/lib, /usr/lib etc).  The idea of this area is to add some
packages to the host that LTIB needs without building a whole host
distribution (or polluting it).  So I don't think you can make use of
this area for what you want (without breaking its intended use).

Your best bet is to make an x86 BSP and build your packages in that
container.  However, you will need to chroot into this area to run your
unit tests.  The reason is glibc is built to find its libraries in /lib,
/usr/lib after deployment to a platform.  So unless you chroot, you're
going to pick up your host's libraries.

Regards, Stuart

On 05/05/13 04:57, Mike Goins wrote:

Build results for 20130509

autobuilder — 2013-05-09T18:38:35

Build results for 20130507

autobuilder — 2013-05-07T19:10:12

Build results for 20130506

autobuilder — 2013-05-06T20:15:11

Build results for 20130503

autobuilder — 2013-05-05T14:29:18

ltib host libs vs x86 platform

Mike Goins — 2013-05-05T03:57:17

I'm implementing some unit testing which requires the same version of
some of the ltib packages (that is, can't depend on the host to have
the same version, even if it is installed).   I thought I could easily
get by with adding the some of the same packages to
host/ltib.preconfig as the platform and set the unit testing
lib/header discovery to /opt/ltib.

The issue with this implementation is that when building host
packages, it does not first find libs/headers in /opt/ltib.  Example
is libxml2, which depends on libz.   libz has been selected for the
host but when building libxml2, the host libz is used instead of
/opt/ltib/usr/lib:

$ ldd /opt/ltib/usr/lib/libxml2.so.2.6.28
linux-vdso.so.1 =>  (0x00007fff56dd2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f075ef9f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f075ed88000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f075ea8b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f075e6cc000)
/lib64/ld-linux-x86-64.so.2 (0x

Build results for 20130503

autobuilder — 2013-05-03T19:09:59

Build results for 20130502

autobuilder — 2013-05-02T19:10:05

Build results for 20130501

autobuilder — 2013-05-01T19:08:03

Build results for 20130430

autobuilder — 2013-04-30T18:37:36