6

I work in a team of 10+ developers and we use RHEL 6.4 for both our development machines as well as our servers (where our software is deployed).

RHEL 6.4 comes with Boost 1.41 but I need fixes that come in at least 1.47. I'd like to upgrade to latest (currently 1.56).

It is not as easy as downloading the source and building/installing, because:

  • I want everyone on our team (including future team members) to have easy access to the new Boost version. Asking everyone to build/install is a lot of trouble and there might be inconsistencies.
  • Our software is deployed as RPMs that get installed on hundreds of servers (and the servers are owned by other teams and outside of our control). These are also running RHEL 6.4. Our software would (presumably) need to run-time link to the new Boost shared libraries on all these machines.

To make matters uglier, RedHat seems to have their own proprietary way of bundling/packaging the Boost software/libraries into RPMs. They don't have just one RPM but a series of smaller RPMs:

$ yum list installed|grep boost
boost.x86_64                          1.41.0-11.el6_1.2           @Workstation  
boost-date-time.x86_64                1.41.0-11.el6_1.2           @Workstation  
boost-devel.x86_64                    1.41.0-11.el6_1.2           @Workstation  
boost-filesystem.x86_64               1.41.0-11.el6_1.2           @Workstation  
boost-graph.x86_64                    1.41.0-11.el6_1.2           @Workstation  
boost-iostreams.x86_64                1.41.0-11.el6_1.2           @Workstation  
boost-program-options.x86_64          1.41.0-11.el6_1.2           @Workstation  
boost-python.x86_64                   1.41.0-11.el6_1.2           @Workstation  
boost-regex.x86_64                    1.41.0-11.el6_1.2           @Workstation  
boost-serialization.x86_64            1.41.0-11.el6_1.2           @Workstation  
boost-signals.x86_64                  1.41.0-11.el6_1.2           @Workstation  
boost-system.x86_64                   1.41.0-11.el6_1.2           @Workstation  
boost-test.x86_64                     1.41.0-11.el6_1.2           @Workstation  
boost-thread.x86_64                   1.41.0-11.el6_1.2           @Workstation  
boost-wave.x86_64                     1.41.0-11.el6_1.2           @Workstation

I have been Googling and can't find an easy solution. I am also somewhat of a newbie when it comes to RPMs.

How can I build/deploy Boost 1.56 as RPM(s) in our situation?

jfritz42
  • 5,913
  • 5
  • 50
  • 66

2 Answers2

5

Sam posted the general strategy (which works): Download the Boost 1.54 source RPM from Fedora 20 and modify it for my purposes.

Here is the extra detail of how I had to edit the boost.spec file to rename the RPMs to jason-boost* and install under /opt/install/thirdparty.

  1. Rename boost.spec to jason-boost.spec. Next, edit jason-boost.spec as follows.

  2. Redefine macros from /usr (default) to /opt/install/thirdparty. Add to top of file:

    # Override installation dirs. We don't want things to go into
# /usr (default) because they would overwrite the system Boost
# library.
%define _prefix /opt/install/thirdparty
%define _defaultdocdir /opt/install/thirdparty/share/doc
%define _mandir /opt/install/thirdparty/share/man

  3. Change Name from "boost" to "jason-boost"

  4. Change Summary to "TBS LTE upgraded version of Boost library (no changes)"

  5. Change toplev_dirname

    • From:

      %define toplev_dirname %{name}_%{version_enc}

    • To:

      %define toplev_dirname boost_%{version_enc}

  6. Change Source0

    • From:

      Source0: http://downloads.sourceforge.net/%{name}/%{toplev_dirname}.tar.bz2

    • To:

      Source0: http://downloads.sourceforge.net/boost/boost_1_54_0.tar.bz2

  7. Rename "boost" sub-packages to "jason-boost"

    • E.g.

      • From:

        Requires: boost-atomic = %{version}-%{release}

      • To:

        Requires: jason-boost-atomic = %{version}-%{release}

    • E.g.

      • From:

        Requires: boost = %{version}-%{release}

      • To:

        Requires: jason-boost = %{version}-%{release}

  8. Add --prefix=/opt/install/thirdparty to bootstrap.sh options

    • From:

      ./bootstrap.sh --with-toolset=gcc --with-icu

    • To:

      ./bootstrap.sh --with-toolset=gcc --with-icu --prefix=/opt/install/thirdparty

  9. Change

    • From:

      %{_includedir}/%{name}

    • To:

      %{_includedir}/boost

  10. Build RPMs without python3, mpich, or openmpi. Python3 isn't easily available unden RHEL 6.4 and mpich and openmpi have all kinds of other compile trouble.

    rpmbuild -ba jason-boost.spec --without python3 --without mpich --without openmpi
jfritz42
  • 5,913
  • 5
  • 50
  • 66
2

Building RPMS in of itself is a skill. Run, don't walk, to the nearest store, and buy a copy of the "Maximum RPM" book, 2nd edition, which will teach you how to build RPMS.

Building RPMS is not exactly rocket science, but it's not something that can be explained a couple of paragraphs, here. I am not very familiar with boost, but a quick check of the packages listed above: on Fedora all of them are built from the same source RPM. It's a single source package, and, as part of building RPMs, the RPM build script automatically chops it up into multiple packages, like the one you see. So, it's really a single package, and the RPM build script.

It might be worth a shot for you to try to rebuild Fedora's boost package from its source RPM, and see if it works for you. The latest boost package for Fedora appears to be 1.54, so 1.56 isn't even built yet. At least not yet on Fedora 20. 21 beta might have a newer boost; I don't know.

Trying to rebuild from source RPMS is worth a shot. It won't take long, it'll either work, or not. Go get a copy of boost-1.54.0-9.fc20.src.rpm from Fedora's download repository; download it on your RHEL box, and try to see what happens:

[user@localhost]$ rpmbuild --rebuild boost-1.54.0-9.fc20.src.rpm

You'll know fairly quick whether it'll work, or not.

But even if this work, you're not of the woods yet. Boost is not binary ABI compatible between releases. Meaning that, as soon as you update your boost packages, you are almost guaranteed to break any existing applications you have, including RHEL packages that link against boost; and rpm may or may not be able to catch that. So, if you get that far, prepare for the possibility of having to rebuild a bunch of other non-boost RPMS, too.

Frederico Martins
  • 1,081
  • 1
  • 12
  • 25
Sam Varshavchik
  • 114,536
  • 5
  • 94
  • 148
  • That book is old and has much that is not up-to-date in it. Though it is a fine start. Fedora has fairly good introductory packaging material on their website. RedHat has a fair amount of good information also. The information about breaking every other boost-using package in the universe is good and should be more heavily emphasized. – Etan Reisner Sep 17 '14 at 00:28
  • The 1st edition of Maximum RPM is outdated. The 2nd edition is a bit dusty, but it's mostly current. – Sam Varshavchik Sep 17 '14 at 00:57
  • That's hardly what I'd call "a bit dusty". The first edition was `1997`. That edition is from `2000`. A number of things have changed since then in terms of best practices/etc. – Etan Reisner Sep 17 '14 at 13:24
  • "Boost is not binary ABI compatible" - that really changes the game. I wonder if I can get Fedora's Boost source RPM and change it to install to a different directory, in order not to overwrite what is already there? Then I can change my app's RPMs to depend on the alternate Boost RPMs. – jfritz42 Sep 17 '14 at 19:08
  • @EtanReisner Do you have a better recommendation on an RPM resource? – jfritz42 Sep 17 '14 at 19:09
  • 1
    @jfritz42 No links unfortunately (though I could dig some up with some searching) but I did give the terms I would search for more-or-less. Both Fedora and RedHat have packaging introductions, guidelines, etc. Also the existing spec file is likely a good place to start from and yes re-using that with an alternate name/prefix is likely a good idea (similar to how the official SCL repositories work I believe). – Etan Reisner Sep 17 '14 at 19:16
  • The place I'm stuck now is that the boost.spec file relies heavily on the _prefix macro for where things will be installed, forcing things to install to /usr. I want things to install to a different location, e.g. /opt/install/thirdparty, so they don't overwrite/interfere with the normal Boost library. Is it possible to change the _prefix in the spec file? – jfritz42 Sep 23 '14 at 17:37
  • You can certainly override the _prefix macro in the spec file, using the --define option to rpmbuild. However that gives you absolutely no guarantees that boost will build correctly with this option. The two unknowns here are 1) the correct set of options to boost's configure script and/or make commands so that boost correctly builds and installs in a non-default location, and 2) whether the boost spec file will actually specify these correct options, if _prefix is overwritten. Once you've determined #1, you can then proceed and figure out #2. – Sam Varshavchik Sep 23 '14 at 22:55
  • FYI to anybody else who finds this answer: This did work for me but it turned out to be a lot of trouble. I'll post another answer with the details. – jfritz42 Sep 26 '14 at 15:56