
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 ========================================================================