Explanation: sigC++ was already linked as transitive dependency
from gtkmm, since it is used for the "signal-slot" system wihin GTK.
But now we want to use sigC++ itself from our generic UI-Backbone,
so we need to pick up the additional compiler and linker flags
and use them when building the relevant parts of both the application
and the test suite
For Lumiera, what we actually need is a GTK-3 compliant libGDL.
Since Mint Rafaela (17.2) has only the rather old version 3.8, we lower
the dependency requirements. Not sure if this causes any problems...
lumiera (0.pre.03-1~rafaela) Lumiera-rafaela; urgency=low
* Rebuild for Mint 17.2 (Rafaela)
* lower requirements on libGDL to 3.8 (a bit outdated, but should do)
* use custom installed gcc-4.9 and libstdc++ 4.9 for building,
since Mint 17.2 has only gcc-4.8 and we need full c++14 compliance
Hint: use add-apt-repository ppa:ubuntu-toolchain-r/test
Author: Hermann Vosseler <deb@ichthyostega.de>
NOTE: we have the policy to always support current Debian/stable
amd at least one Ubuntu LTS release, unless hard dependency problems prevent that.
Currently, Ubuntu/Trusty is already a bit dated, but the only problematic dependency
could be libboost (1.54 in Trusty, 1.55 in Jessie).
GCC-4.8 can be replaced by GCC-4.9 in Trusty without problems
It is always a bit tricky to find out the precise lower boundary,
so we try to upgrade these requirements as our platform progresses.
For now we have used the level available on Ubuntu/Trusty to set
the lower constraints for most libraries
For the Gnome Docking Library, a recent official version will do.
For the mm-bindings by Fabien Parent we maintain our own debian package
at Lumiera.org/debian (there is no official debian package yet)
we still don't check for the precise boost version number in the
SCons configuration. We might do so in future, but for now our
policy is that precise version dependency checking is the business
of the packager (i.e. the debian package). The SCons build just
has to ensure the absolute necessary baseline
This improves sane library dependencies, as mandated
by debian policy. Some of the librt functions are in such
wide use, that we'd get them through transitive dependencies
anyway. But linking explicitly against a function adds the
DT_NEEDED for this library to our build artefacts. This is
correct, since we're actually using these functions ourselves,
making them into direct dependencies.
The XV-Viewer widget in our GUI uses four direct calls
to the X-Lib. This was discovered by strict dependency checking,
as mandated by new Debian policy
Note: this drops some backwards compatibility. We're targeting now
roughly the range between Ubuntu-Precise (LTS) and Debian/testing,
with Debian/stable as the reference system.
The naming scheme for Boost-Libraries was adjusted with Boost-1.42
for Unix-Platforms. Now the '-mt' suffix isn't included any more, but
the libraries available through the usual packaging mechanisms can be
assumed to be thread safe.
See also http://issues.lumiera.org/ticket/759
