packaging boost-1.37.0 for "LTIB"?
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: =========================== cut here ============================ %define pfx /opt/freescale/rootfs/%{_target_cpu} %define __unzip unzip -a Summary : c++ libraries Name : boost Version : 1.31.0 Release : 1 Vendor : Freescale Packager : Stuart Hughes Group : System Environment/Libraries Source : %{name}_1_31_0.tar.bz2 Patch0 : boost-1.31.0-regex-patch-20040503.zip License : Boost (distributable) BuildRoot : %{_tmppath}/%{name} %Description %{summary} %Prep %setup -n %{name}_1_31_0 cd $RPM_BUILD_DIR/%{name}_1_31_0/boost/regex/v4 %{__unzip} -o $RPM_SOURCE_DIR/boost-1.31.0-regex-patch-20040503.zip %Build %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 %Clean rm -rf $RPM_BUILD_ROOT %Files %defattr(-,root,root) %{pfx}/* ==================== cut here ================= so, a couple short questions that might save me some time before i dig into the source: 1) does 1.37.0 still require a "regex" patch? apparently, the patch mentioned above was to address some regex issues identified after 1.31.0 was released? i'm ready to assume that anything that significant has been resolved since then. 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. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================
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
1) does 1.37.0 still require a "regex" patch? apparently, the patch mentioned above was to address some regex issues identified after 1.31.0 was released? i'm ready to assume that anything that significant has been resolved since then.
I would assume that it has been resolved.
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. In Christ, Steven Watanabe
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
... snip ...
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
"out of date" with respect to what? remember, this is boost-1.31.0 so it might be that that bjam syntax is correct for back then, no? or am i misunderstanding something here? rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================
AMDG Robert P. J. Day wrote:
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
"out of date" with respect to what?
It won't work with boost 1.37. It should have worked before 1.34.
remember, this is boost-1.31.0 so it might be that that bjam syntax is correct for back then, no?
Yep. In Christ, Steven Watanabe
On Sat, 3 Jan 2009, Steven Watanabe wrote:
AMDG
Robert P. J. Day wrote:
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
"out of date" with respect to what?
It won't work with boost 1.37. It should have worked before 1.34.
remember, this is boost-1.31.0 so it might be that that bjam syntax is correct for back then, no?
Yep.
i got the LTIB packaging for boost-1.37.0 to work just by simplifying things down to their essense. the relevant part of the .spec file is now: ======================== ... %Build ./configure --prefix=$RPM_BUILD_ROOT/%{pfx}/%{_prefix} \ --with-bjam=/home/rday/bin/bjam make %Install rm -rf $RPM_BUILD_ROOT make install ... ========================= where /home/rday/bin/bjam is the result of doing a native configure, grabbing the native compilation of bjam, stashing it to the side where it would be found, then allowing boost to be build via LTIB, which (as i mentioned in an earlier post) wraps the entire build process with some aliases so that all compilation is done transparently with a cross-compile toolchain. and that seemed to work, barring a bunch of bzip2-related errors that i can see explained on the web page. so things seem to be humming along for now. thanks for all the guidance. i'm sure i'll have more silly questions in the near future. rday p.s. i'm assuming, then, that all that earlier python stuff you can see above is no longer necessary since, AFAICT, i don't need it now for 1.37.0. -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================
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 ========================================================================
AMDG Robert P. J. Day wrote:
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.
Can you build bjam for the host system first?
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.
This isn't quite true, but the result is the same. build.sh first builds jam0 which it then uses to build bjam. The tool used by make install is bjam. In Christ, Steven Watanabe
On Sat, 3 Jan 2009, Steven Watanabe wrote:
AMDG
Robert P. J. Day wrote:
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.
Can you build bjam for the host system first?
this is, in fact, what i did -- "./configure", then stuck the resulting bjam in my personal bin directory, and used that for the subsequent cross-compile build. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================
participants (2)
-
Robert P. J. Day -
Steven Watanabe