Re: [Boost-users] packaging boost-1.37.0 for "LTIB"?

Subject: Re: [Boost-users] packaging boost-1.37.0 for "LTIB"?
From: Robert P. J. Day (rpjday_at_[hidden])
Date: 2009-01-03 14:51:37

On Sat, 3 Jan 2009, Steven Watanabe wrote:

> AMDG
>
> Robert P. J. Day wrote:
> >   i want to package the latest version of boost for the LTIB software
> > package so, to make a long story short, here's the RPM packaging spec
> > file for an older version:
> > <snip>
> >
> > %Install
> > rm -rf $RPM_BUILD_ROOT
> > mkdir -p $RPM_BUILD_ROOT/%{pfx}/%{_prefix}
> > (cd tools/build/jam_src && ./build.sh)
> > BJAM=`find tools/build/jam_src/ -name bjam -a -type f`
> > PYTHON_VERSION=`python -V 2>&1 |sed 's,.*
> > \([0-9]\.[0-9]\)\(\.[0-9]\)\?.*,\1,'`
> > PYTHON_FLAGS="-sPYTHON_ROOT=%{_prefix} -sPYTHON_VERSION=$PYTHON_VERSION"
> > $BJAM $PYTHON_FLAGS -sTOOLS=gcc -sBUILD="debug release"
> > --prefix=$RPM_BUILD_ROOT/%{pfx} %{_prefix} install
>
> > 2) i'm also assuming that JAM is required for that final packaging
> > step so that part of the spec file is still relevant.
> >
> >   in other words, other than dropping the regex patch and updating the
> > version number, does the above spec file look about right for 1.37.0?
> > i'm about to give it a try.  thanks.
> >
>
> The bjam syntax is out of date.
> echo "using python : $PYTHON_VERSION : %{_prefix} ;" >user-config.jam
> $BJAM --user-config=user-config.jam toolset=gcc debug release
> --prefix=$RPM_BUILD_ROOT/%{pfx} %{_prefix} install
>
> should be closer, although the use of %{_prefix} in the bjam command is
> probably wrong since I'm not sure what it was supposed to do.

  after more experimentation, this is what appears to be the issue and
i'm not sure it's anything that the boost list can help with.

  LTIB is a packaging system used to build cross-compiled root
filesystems (a la buildroot, sort of like that).  what makes LTIB a
bit different is that the entire build runs inside a "spoofed"
environment, where normal executable names like "gcc" and "ld" and so
on are aliased to their cross-compile counterparts.  in other words,
packages are built "normally", allegedly never realizing that their
invocations of the compiler tools are actually being redirected to
their cross-compiler equivalents.

  most of the time, this works just fine, but it runs into problems if
part of the build *needs* to invoke the native tools, and i think
that's what's happening when you try to "make install" after the
build.

  as i read it, "make install" requires jam, correct, which it would
find in tools/jam/src/bootstrap/jam0?  and this executable does in
fact exist, but it's the *cross-compiled* version, and therefore of no
use on the build system.

  does this make sense?  for a "normal" package, running "make
install" would normally work fine, as it would involve running things
like "mkdir" and "install".  but boost appears to be different in that
it needs a tool that's created as part of the build process, and which
is -- because of the way LTIB works -- built for the *target* system.

  at least, that's what *appears* to be happening.  i *can* verify
that the executable named "jam0" that's is trying to be run is
cross-compiled for the m68k, the target system here, and that seems to
be why the installation step is failing.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.
http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================