Re: [Ltib] is the "boost" package actually supposed to build?

[Stuart Hughes]

Hi Robert,

A few pointers:

* Any package not selectable from the config system (e.g. with ./ltib -m
config) is not supported.  Generally these spec files are there because
people started working on them and stopped, or they worked on previous
projects.  You could argue they should be removed, but my view is that
they are a better starting point than none.

* These unfinished .spec files usually need work.  For something like
boost, you need to look at similar packages than build executables that
they need to run in order to progress.  If you're lucky, the package is
aware of this and you can simply pass HOSTCC="$BUILDCC" to the 'make'
line.  If you're less lucky, you have to get into elaborate hackery such
as that in the perl.spec; essentially build twice, once native, once
cross using the native parts you need during the cross build.

* The 'aliases' of gcc etc to the cross toolchains is more than just
simple $tool = ${CROSS_COMPILE}$tool.  It also makes sure that:
   * The right interface area rootfs/usr/{include,lib} is
     used without needing -I -L.
   * Any mandatory flags to gcc are guaranteed to be injected,
     these are setup by LTIB as the env: TOOLCHAIN_CFLAGS

* Conventionally, if a tool to run on the build machine has to be built,
  and it will be needed after the package has been built, it should get
  put into _ltib_/bin.  This happens with the build machine cross gdb
  for example (the bit you need to work with gdbserver on the target).
  These need to be put under the project as your target may have some
  very specific build requirements.

* The spec file should build the package in one single run (even if
  internally it has to build twice like Perl).

Regards, Stuart

On Wed, 2009-01-07 at 16:35 -0500, Robert P. J. Day wrote:
>    i decided to add "boost" to my LTIB build, and it failed thusly:
> 
> ...
> ./bootstrap.gcc/jam0 -f build.jam --toolset=gcc --toolset-root= clean
> ./build.sh: line 16: ./bootstrap.gcc/jam0: cannot execute binary file
> ...
> 
>    from what i can tell, this package shouldn't even build under LTIB,
> for what i *think* is the following reason.
> 
>    if i understand the way LTIB works, it wraps the entire build process
> with a set of aliases for the standard build tools (gcc, ld, as, ...),
> so that the package build process can remain unchanged, but those names
> are redirected to the appropriate cross-compiler tools, is that correct?
> but if that's the case, then for a package to be LTIB-buildable, the
> *entire* process must be redirectable to those cross utilities.
> 
>    that's not the case with boost.  when it comes time to "install"
> boost, the installation process insists on building the "bjam" utility
> with which it will do the installation.  but LTIB will cause that
> utility to be built cross-compiled (i've verified that), at which
> point the installation *must* fail because bjam can't run on the host.
> 
>    i tested this with the much newer boost-1.37.0, and i get exactly
> the same error.  the way around it for me was to do a regular
> configure of the boost software, grab the (native) "bjam" utility
> that was created, and dump it in /home/rday/bin/bjam.   at that
> point, here's my spec file for boost-1.37.0:
> 
> %define pfx /opt/freescale/rootfs/%{_target_cpu}
> 
> Summary         : c++ libraries
> Name            : boost
> Version         : 1.37.0
> Release         : 1
> Vendor          : Freescale
> Packager        : Robert P. J. Day
> Group           : System Environment/Libraries
> Source          : %{name}_1_37_0.tar.bz2
> License         : Boost (distributable)
> BuildRoot       : %{_tmppath}/%{name}
> 
> %Description
> %{summary}
> 
> %Prep
> %setup -n %{name}_1_37_0
> 
> %Build
> ./configure --prefix=$RPM_BUILD_ROOT/%{pfx}/%{_prefix} \
>    --with-bjam=/home/rday/bin/bjam     <--- that solves the problem
> make
> 
> 
> %Install
> rm -rf $RPM_BUILD_ROOT
> make install
> 
> %Clean
> rm -rf $RPM_BUILD_ROOT
> 
> 
> %Files
> %defattr(-,root,root)
> %{pfx}/*
> 
>    have i missed something?  given that part of the package installation
> *requires* doing a native compile, how would this have ever worked
> without that little workaround?
> 
>    in any event, the above is how to compile boost-1.37.0 if anyone is
> interested.  you'll still get some build errors for portions of the
> software but they're to be expected and are documented at the boost
> site.
> 
>    thoughts?
> 
> rday
> 
> 
> 
> 
> _______________________________________________
> LTIB home page: http://bitshrine.org
> 
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib