5

I am trying to create a debian package for a project of mine, but have been running into issues with boost version support.

I have indeed looked at this question. It is similar but the provided solutions (Build-Depends) are not really applicable to me as I am making a binary installer.

Basically, my installed libraries and executables always link to libboost_(component).so.1.46 instead of the symbolic link library libboost_(component).so. Leaving my debian installer only usable by people with my exact boost version. I'm using CPack to make the debian package and my depends line looks like:

SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libboost-dev (>= 1.46),
                                  libboost-thread-dev (>= 1.46),
                                  libboost-signals-dev (>= 1.46),
                                  libboost-system-dev (>= 1.46), 
                                  libboost-filesystem-dev (>= 1.46),
                                  libboost-python-dev (>= 1.46), ..." )

Do I need to build separate installers for each platform on said platform or with that platform's boost version?

Community
  • 1
  • 1
kelano
  • 293
  • 3
  • 14

2 Answers2

3

while i understand your intenstion that you want to create a package that works with all boost versions, you really have to ask yourself whether this is actually possible.

the idea of .so versions (e.g. .so.1.46 vs .so.1.48) is really to indicate that the library interface (ABI) has changed, which basically indicates library incompatibilities.

therefore, it is highly unlikely, that your application linking against libboost_foo.so.1.46 will actually work with libboost_foo.so.1.48. it could well be, that symbols needed by your application have suddenly vanished (so your application will refuse to start). worse, it could be that the meaning of a symbol has changed between versions, leading to hard to track undefined behaviour.

this is the reason, why whenever you link against libfoo.so, the binary really links against libfoo.so.1 (or wherever libfoo.so really points)

now debian policy is, that the package name has to change for any incompatible ABI change. this basically allows the user to have two versions of the same library installed at the same time (e.g. boost-1.46 and boost-1.49).

if you are targetting a specific version of Debian, you can be sure that a specific version of a library will be available. e.g. on Debian/wheezy you will have boost-1.49. so if you provide packages fro Debian/wheezy, you only need to link against boost-1.49. this is also one of the reasons why releases are so great: it kind of guarantees that all needed lbiraries are available.

it also means, that you can have different package versions of the same application in multiple Debian releases, even though there has been no "upstream" release: the packages had to be rebuild because of an upgrade (involving a soname change) of a dependency

so to conclude:

  • linking to the actual library version is a feature to keep your system sane

  • debian allows to have multiple versions of the same library installed at the same time

solution for your problem:

  • provide binary packages for each soname release of any dependency

providing packages for each debian release will make this much less troublesome than it seems (as each release has only a fixed set of libraries).

umläute
  • 28,885
  • 9
  • 68
  • 122
  • Thanks for the response. Oddly enough, my application does in fact work as is with boost 1.46, 1.48, and 1.49 without a hitch. It would appear my options are (a) build a new debian installer per Ubuntu version I want to support or (b) install boost 1.46 on every machine even if it has a later boost version. I think (a) sounds like a better option and probably worth the hassle. – kelano Jul 18 '13 at 14:30
  • what does "work as is" mean? can you compile your application again any version of boost, or does it keep working even if you exchange `libboost_foo.so.1.46.0` with `libboost_foo.s.1.49.0`? anyhow, if it does work it is mere luck (which depends on how many symbols you really import from the the library). – umläute Jul 18 '13 at 16:48
  • anyhow, your solution (a) is indeed the way to go (though i don't know where `ubuntu` replaced `debian` in this game :-)) – umläute Jul 18 '13 at 16:48
  • What I mean is people have compiled, linked, and run my source code against several versions of boost without a problem. I think I have been lucky to use boost components that have not received an API update. I will, like you said, try to go with (a) for that reason. – kelano Jul 18 '13 at 18:48
  • your experience shows that boost (or at least the parts you are using) keeps *API* compatibility; this is not directly related to *ABI* compatibility. (using some macros it's easy to have completely different API (symbols in the source code) and ABI (symbols on the linker level) – umläute Jul 18 '13 at 19:19
1

What you could try to do is link boost packages statically:

set(Boost_USE_STATIC_LIBS ON)

lisu
  • 2,213
  • 14
  • 22