Should your build systems be up to date?

A recent post on the mailing list for Tao Presentations beta got me thinking: should build systems be up to date?

The poster explains:

Regarding the ubuntu version, was it build with a g++ 4.6 ?
It seems to require a GLIBCXX_3.4.15 which is just above the one I have
on Natty.

I am going to install a g++ 4.6 from source in order to get the right
libstdc++ but I wanted to let you know just in case someone else get the
same issue.

So here is the problem : if we upgrade our build systems to the latest and greatest patch level, we will also include a number of recent dependencies that our customers may not have yet.

Some development environments provide options to select which build tools you use, allowing you to revert to older build configurations. For example, my MacOSX system shows the following variants of G++:

g++            g++-4.0        g++-apple-4.2  g++2
g++-3.3        g++-4.2        g++-mp-4.4     g++3

Unfortunately, that facility doesn’t automatically extend to all the libraries you depend on. For example, we use Qt to develop cross-platform GUI code, and versions before the still unreleased 4.8 version emit compilation warnings while compiling on MacOSX Lion. So if I want to build with Lion, my options are either to build in an unsupported configuration (and stop using the -Wall option in our builds), or to build with a not-yet-released library.

So is the best solution to keep your build systems behind, with all the implied security risks? Is there a better overall strategy I didn’t think of?

3 thoughts on “Should your build systems be up to date?

  1. Welcome to an imperfect world.

    As much as possible, *try* to use the latest greatest platforms (OS, tools and libs and gcc with -Wall -Werror) while you develop and test (best effort approach), and then also test and maintain releases with adapted options/libs on the targets you want to ship for. Because you have to deliver now on current platforms with all their faults, and might want to know now the faults of future platforms to be ready to ship when they become current.

  2. Hi foo,

    The problem is not for dev and test systems. It is for the actual build systems used to create the final image. Unless you find a way to produce on recent systems binaries that run for the majority of your customers, you may have to leave your system (or at least a part of it) in an outdated state.

    Note that in my experience, the problem is more annoying on Linux (where building from source is the norm, hiding the problem for most) than, say, on Windows.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s