New Boost RPM spec file
In my company's use of Boost, we have found that the Boost RPM installed with Linux distributions such as Fedora Core and Red Hat Enterprise Linux does not quite meet our needs. This happens because that RPM does not install the multi-threaded versions of the libraries, nor does it preserve the version information on the installed libraries. I have attached an RPM spec file that addresses these issues and that allows targeting 32-bit Linux from an x86_64 installation (though it has to exclude Boost.Python and Boost.iostreams). Personally, I would like to see Boost RPMs built that follow the existing Boost conventions more closely, but that may not be a popular view. If nothing else, I thought that posting this file would be helpful to people who have run into the same issues that we have seen. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/ %define tarball_name boost_1_33_1 %define python_arch %(python -c 'import os; print os.uname()[4]') %if %{python_arch} == %{_arch} %define build_python 1 %else %define build_python 0 %endif Name: boost Summary: The Boost C++ Libraries Version: 1.33.1 Release: 1 License: Boost Software License URL: http://www.boost.org/ Group: System Environment/Libraries Source: %{tarball_name}.tar.bz2 BuildRoot: %{_tmppath}/boost-%{version}-root Prereq: /sbin/ldconfig BuildRequires: libstdc++-devel python Obsoletes: boost <= 1.33.0 Obsoletes: boost-devel <= 1.33.0 Obsoletes: boost-doc <= 1.33.0 %if %{build_python} Obsoletes: boost-python <= 1.33.0 %endif %description Boost provides free peer-reviewed portable C++ source libraries. The emphasis is on libraries which work well with the C++ Standard Library. One goal is to establish "existing practice" and provide reference implementations so that the Boost libraries are suitable for eventual standardization. (Some of the libraries have already been proposed for inclusion in the C++ Standards Committee's upcoming C++ Standard Library Technical Report.) %package devel Summary: The Boost C++ Headers Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Obsoletes: boost-python-devel <= 1.33.0 Provides: boost-python-devel = %{version}-%{release} %endif %description devel Headers for the Boost C++ libraries %package doc Summary: The Boost C++ html docs Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Provides: boost-python-docs = %{version}-%{release} %endif %description doc HTML documentation files for Boost C++ libraries %prep rm -rf $RPM_BUILD_ROOT %setup -n %{tarball_name} -q %ifarch i386 i486 i586 i686 %define arch_args <cflags>-m32 <cxxflags>-m32 <linkflags>-m32 <linkflags>-L/usr/lib %else %ifarch x86_64 %define arch_args <cflags>-m64 <cxxflags>-m64 <linkflags>-m64 <linkflags>-L/usr/lib64 %endif %endif %build without_libs='' %if %{build_python} == 0 without_libs="$without_libs --without-python" %endif # This is a hack. A better way needs to be devised for determining when # the local architecture does not match the target architecture. %if %{python_arch} != %{_arch} without_libs="$without_libs --without-iostreams" %endif #build bjam (cd tools/build/jam_src && ./build.sh) #build boost with bjam 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=/usr -sPYTHON_VERSION=$PYTHON_VERSION" $BJAM $PYTHON_FLAGS "-sTOOLS=gcc" "-sBUILD=release <threading>single/multi %{arch_args}" "--prefix=$RPM_BUILD_ROOT%{_prefix}" $without_libs stage %install mkdir -p $RPM_BUILD_ROOT%{_libdir} mkdir -p $RPM_BUILD_ROOT%{_includedir} mkdir -p $RPM_BUILD_ROOT%{_docdir} mkdir -p $RPM_BUILD_ROOT%{_docdir}/boost-%{version} tar -C stage/lib -cvf - . | tar -C $RPM_BUILD_ROOT%{_libdir} -xpf - # install include files for i in `find boost -type d`; do mkdir -p $RPM_BUILD_ROOT%{_includedir}/$i done for i in `find boost -type f`; do install -m 644 $i $RPM_BUILD_ROOT%{_includedir}/$i done #install doc files cd doc/html; for i in `find . -type d`; do mkdir -p $RPM_BUILD_ROOT%{_docdir}/boost-%{version}/$i done for i in `find . -type f`; do install -m 644 $i $RPM_BUILD_ROOT%{_docdir}/boost-%{version}/$i done cd ../..; %clean rm -rf $RPM_BUILD_ROOT %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-, root, root) %{_libdir}/*.so.%{version} %files devel %defattr(-, root, root) %{_includedir}/boost %{_libdir}/*.a %{_libdir}/*.so %files doc %defattr(-, root, root) %{_docdir}/boost-%{version} %changelog * Apr 14 2006 Patrick Hartling <patrick@infiscape.com> 1.33.1-1 - Update to 1.33.1 - Install single- and multi-threaded libraries - Install fully versioned libraries - Allow 32-bit build to be made on 64-bit architecture (currently without Boost.Python or Boost.iostreams) * Mon Nov 29 2004 Benjamin Kosnik <bkoz@redhat.com> 1.32.0-1 - Update to 1.32.0 - (#122817: libboost_*.so symlinks missing) * Wed Sep 22 2004 Than Ngo <than@redhat.com> 1.31.0-9 - cleanup specfile - fix multiarch problem * Tue Jun 15 2004 Elliot Lee <sopwith@redhat.com> - rebuilt * Wed May 05 2004 Warren Togami <wtogami@redhat.com> 1.31.0-7 - missing Obsoletes boost-python * Mon May 03 2004 Benjamin Kosnik <bkoz@redhat.com> - (#121630: gcc34 patch needed) * Wed Apr 21 2004 Warren Togami <wtogami@redhat.com> - #121415 FC2 BLOCKER: Obsoletes boost-python-devel, boost-doc - other cleanups * Tue Mar 30 2004 Benjamin Kosnik <bkoz@redhat.com> - Remove bjam dependency. (via Graydon). - Fix installed library names. - Fix SONAMEs in shared libraries. - Fix installed header location. - Fix installed permissions. * Fri Feb 13 2004 Elliot Lee <sopwith@redhat.com> - rebuilt * Mon Feb 09 2004 Benjamin Kosnik <bkoz@redhat.com> 1.31.0-2 - Update to boost-1.31.0 * Thu Jan 22 2004 Benjamin Kosnik <bkoz@redhat.com> 1.31.0-1 - Update to boost-1.31.0.rc2 - (#109307: Compile Failure with boost libraries) - (#104831: Compile errors in apps using Boost.Python...) - Unify into boost, boost-devel rpms. - Simplify installation using bjam and prefix install. * Tue Sep 09 2003 Nalin Dahyabhai <nalin@redhat.com> 1.30.2-2 - require boost-devel instead of devel in subpackages which require boost-devel - remove stray Prefix: tag * Mon Sep 08 2003 Benjamin Kosnik <bkoz@redhat.com> 1.30.2-1 - change license to Freely distributable - verify installation of libboost_thread - more boost-devel removals - deal with lack of _REENTRANT on ia64/s390 - (#99458) rpm -e fixed via explict dir additions - (#103293) update to 1.30.2 * Wed Jun 04 2003 Elliot Lee <sopwith@redhat.com> - rebuilt * Tue May 13 2003 Florian La Roche <Florian.LaRoche@redhat.de> - remove packager, change to new Group: * Tue May 06 2003 Tim Powers <timp@redhat.com> 1.30.0-3 - add deffattr's so we don't have unknown users owning files
Patrick Hartling wrote:
In my company's use of Boost, we have found that the Boost RPM installed with Linux distributions such as Fedora Core and Red Hat Enterprise Linux does not quite meet our needs. This happens because that RPM does not install the multi-threaded versions of the libraries, nor does it preserve the version information on the installed libraries. I have attached an RPM spec file that addresses these issues and that allows targeting 32-bit Linux from an x86_64 installation (though it has to exclude Boost.Python and Boost.iostreams).
Personally, I would like to see Boost RPMs built that follow the existing Boost conventions more closely, but that may not be a popular view. If nothing else, I thought that posting this file would be helpful to people who have run into the same issues that we have seen.
I build an rpm also that installs in parallel to Fedora. This is needed because some other Fedora packages depend on the standard Fedora boost rpm, but as you said, I want a boost rpm that is more like the boost standard. Also, I added a couple of my own patches. Find it here: http://nbecker.dyndns.org:8080/boost-nb-1.33.1-3.src.rpm
I for one would really appreciate it if the boost community was able to produce a recommended spec file for building and installing boost rpms and correspondingly for packaging boost up with other package management tools. The current situation for developers using packaged versions of boost ranges from painful to downright impossible. Developer to rely upon packagers to follow any of the standard boost conventions. Unfortunately this hurts my use of boost and makes it so I have to include my own builds with any applications I distribute. If the boost community created and maintained a set of recommended packaging files and conventions this problem could largely be eliminated. Doesn't this cause problems for anyone else? -Allen Neal Becker wrote:
Patrick Hartling wrote:
In my company's use of Boost, we have found that the Boost RPM installed with Linux distributions such as Fedora Core and Red Hat Enterprise Linux does not quite meet our needs. This happens because that RPM does not install the multi-threaded versions of the libraries, nor does it preserve the version information on the installed libraries. I have attached an RPM spec file that addresses these issues and that allows targeting 32-bit Linux from an x86_64 installation (though it has to exclude Boost.Python and Boost.iostreams).
Personally, I would like to see Boost RPMs built that follow the existing Boost conventions more closely, but that may not be a popular view. If nothing else, I thought that posting this file would be helpful to people who have run into the same issues that we have seen.
I build an rpm also that installs in parallel to Fedora. This is needed because some other Fedora packages depend on the standard Fedora boost rpm, but as you said, I want a boost rpm that is more like the boost standard.
Also, I added a couple of my own patches.
Find it here: http://nbecker.dyndns.org:8080/boost-nb-1.33.1-3.src.rpm
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Allen Bierbaum <allenb@vrsource.org> writes:
I for one would really appreciate it if the boost community was able to produce a recommended spec file for building and installing boost rpms and correspondingly for packaging boost up with other package management tools.
You're a member of the community, aren't you? :) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Allen Bierbaum <allenb@vrsource.org> writes:
I for one would really appreciate it if the boost community was able to produce a recommended spec file for building and installing boost rpms and correspondingly for packaging boost up with other package management tools.
You're a member of the community, aren't you? :)
Yes. :) So I guess the question would be, is there interest from the boost admins in accepting an rpm spec file (based on Patrick and Neal's work) and making it the recommended way for packagers to build boost. Or said another way, is there interest in putting the boost seal of approval on packaging and installation methods? If there is interest, what are the next steps for getting an rpm spec file accepted? -Allen
Allen Bierbaum <allenb@vrsource.org> writes:
David Abrahams wrote:
Allen Bierbaum <allenb@vrsource.org> writes:
I for one would really appreciate it if the boost community was able to produce a recommended spec file for building and installing boost rpms and correspondingly for packaging boost up with other package management tools.
You're a member of the community, aren't you? :)
Yes. :)
So I guess the question would be, is there interest from the boost admins in accepting an rpm spec file (based on Patrick and Neal's work) and making it the recommended way for packagers to build boost. Or said another way, is there interest in putting the boost seal of approval on packaging and installation methods?
I am interested.
If there is interest, what are the next steps for getting an rpm spec file accepted?
Post it along with an explanation of what it does and rationale for your choices, I guess. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Allen Bierbaum <allenb@vrsource.org> writes:
David Abrahams wrote:
Allen Bierbaum <allenb@vrsource.org> writes:
So I guess the question would be, is there interest from the boost admins in accepting an rpm spec file (based on Patrick and Neal's work) and making it the recommended way for packagers to build boost. Or said another way, is there interest in putting the boost seal of approval on packaging and installation methods?
I am interested.
If there is interest, what are the next steps for getting an rpm spec file accepted?
Post it along with an explanation of what it does and rationale for your choices, I guess.
Another, but related, question would be whether that could be abstracted a little along these lines: * how much of the info can be extracted from the build system automatically ? * what (meta)data needs to be added by developers manually ? * can the same process be repeated for other packagers, such as deb or msi ? If that's possible, may be packaging could be a new boost.build feature ? I guess these questions are more relevant to the boost.build ML, so I'm Cc'ing them there. Regards, Stefan
Stefan Seefeld wrote:
Another, but related, question would be whether that could be abstracted a little along these lines:
* how much of the info can be extracted from the build system automatically ? * what (meta)data needs to be added by developers manually ? * can the same process be repeated for other packagers, such as deb or msi ?
Sorry, that wasn't particularly clear. Let me add: * Can the process be abstracted such that the same input can be used to generate a variety of packages automatically ? Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Stefan Seefeld wrote:
Another, but related, question would be whether that could be abstracted a little along these lines:
* how much of the info can be extracted from the build system automatically ? * what (meta)data needs to be added by developers manually ? * can the same process be repeated for other packagers, such as deb or msi ?
Sorry, that wasn't particularly clear. Let me add:
* Can the process be abstracted such that the same input can be used to generate a variety of packages automatically ?
Yes, a good goal, and one we've been discussing for some time on the Boost.Build list. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Stefan Seefeld escreveu:
If that's possible, may be packaging could be a new boost.build feature ? I guess these questions are more relevant to the boost.build ML, so I'm Cc'ing them there.
I've been thinking on trying to extend Boost.Build to allow "msi" targets based on the WiX toolset: http://wix.sourceforge.net/ WiX works with a compiler/linker model, so it shouldn't be that difficult to just imitate some of the original toolsets. -- Pedro Lamarão
On Wed, May 17, 2006 at 10:08:26AM -0500, Allen Bierbaum wrote:
Doesn't this cause problems for anyone else?
Yes, I've avoided boost for many, many years, because it was so hard to compile and install right. The ONLY reason I now finally started to use it, is because my dist (fedora) have made rpms for it. Without ready to go packages, I wouldn't use boost. I can imagine that for developers who need bleeding-edge boost, this is (still) something very painful. -- Carlo Wood <carlo@alinoe.com>
Neal Becker wrote:
Patrick Hartling wrote:
In my company's use of Boost, we have found that the Boost RPM installed with Linux distributions such as Fedora Core and Red Hat Enterprise Linux does not quite meet our needs. This happens because that RPM does not install the multi-threaded versions of the libraries, nor does it preserve the version information on the installed libraries. I have attached an RPM spec file that addresses these issues and that allows targeting 32-bit Linux from an x86_64 installation (though it has to exclude Boost.Python and Boost.iostreams).
Personally, I would like to see Boost RPMs built that follow the existing Boost conventions more closely, but that may not be a popular view. If nothing else, I thought that posting this file would be helpful to people who have run into the same issues that we have seen.
I build an rpm also that installs in parallel to Fedora. This is needed because some other Fedora packages depend on the standard Fedora boost rpm, but as you said, I want a boost rpm that is more like the boost standard.
Also, I added a couple of my own patches.
Find it here: http://nbecker.dyndns.org:8080/boost-nb-1.33.1-3.src.rpm
This is an interesting approach. I hadn't thought about stripping out the toolset name or the version information in the base library name. Having the version information in the file name twice is probably not necessary for this case, and it seems safe to assume that GCC will usually be the toolset used for Linux. I don't know if the Intel Compiler toolset case needs to be taken into account. After thinking more about how your RPM will install in parallel with the Fedora Core RPM, I got to thinking about parallel Boost installations in general. I am starting to think that it could be very beneficial to allow for Boost headers to be installed in parallel via an RPM--especially if Boost releases start happening more frequently. Considering the way that Boost is built and installed outside the scope of an RPM, it seems like this is the intention. Is that a fair assessment? -Patrick P.S. Aside from boost-base.patch, what do the other patches do? -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Patrick Hartling wrote:
P.S. Aside from boost-base.patch, what do the other patches do?
boost-wave is to build wave shared (is this in boost cvs?) boost-mt is my own patch to mersenne twister to add serialization support boost-ublas is my own patch to ublas vector to bypass default construction boost-serial is I think now in boost cvs to support build with new gcc (>= 4.1?)
On Monday, May 15, 2006 2:39 PM -0500 Patrick Hartling <patrick@137.org> wrote:
In my company's use of Boost, we have found that the Boost RPM installed with Linux distributions such as Fedora Core and Red Hat Enterprise Linux does not quite meet our needs.
In developing an "upstream" RPM, it's probably a good idea to keep in mind the packaging standards of the consuming distros. Here's the relevant pages for Fedora: <http://fedoraproject.org/wiki/Packaging/Guidelines> <http://fedoraproject.org/wiki/Packaging/ReviewGuidelines> Anyone have pointers to the standards used by other distros?
participants (8)
-
Allen Bierbaum -
Carlo Wood -
David Abrahams -
Kenneth Porter -
Neal Becker -
Patrick Hartling -
Pedro Lamarão -
Stefan Seefeld