FTBFS with boost 1.66+

[mikhirev]

Hi!

liblsl 1.12.0 fails to build in Fedora 28 and rawhide. The error message is

In file included from /builddir/build/BUILD/liblsl-1.12.0/src/data_receiver.h:7,
                 from /builddir/build/BUILD/liblsl-1.12.0/src/data_receiver.cpp:7:
/builddir/build/BUILD/liblsl-1.12.0/src/cancellable_streambuf.h:43:61: error: 'stream_socket_service' does not name a type; did you mean 'make_service'?
   template <typename Protocol, typename StreamSocketService=stream_socket_service<Protocol> >
                                                             ^~~~~~~~~~~~~~~~~~~~~
                                                             make_service

Since boost 1.66.0 asio service template parameters and corresponding classes are disabled by default. This patch fixes the issue, but I'm not sure about its compatibility with older boost versions. Another possible solution is to define the BOOST_ASIO_ENABLE_OLD_SERVICES macro.

[tstenner]

liblsl shouldn't even depend on boost. Could you paste the commit id and the build command?

[tstenner]

I looked at the build, apparently you are using the last official release from 2016? liblsl shouldn't use anything from system boost since some months, but the next release probably won't be before the meetup in september.

[mikhirev]

I looked at the build, apparently you are using the last official release from 2016?

Yes, it's a stable release.

liblsl shouldn't use anything from system boost since some months

OMG, I'll need to unbundle boost…

It's a very bad idea. Any Linux distro policy (not only Fedora) prohobits using bundled libraries because they are not maintainable. So in this package I simply dropped the external directory to use system libraries whenever possible.

[mgrivich]

Scientific software such as LSL often has different goals than Linux distros. Specifically, we can't have code changing and producing unexpected effects, like can happen when an OS package manager updates a library. For this reason, yes, we bundle all libraries with LSL.

This is not a theoretical discussion. For example, it is known that later versions of boost cause significant performance issues on Windows. This type of change, if uncontrolled by us, can blindside an experimenter and lead to bad data.

[mikhirev]

I understand that in some cases bundling libraries is required, especially speaking about Windows. But please don't make it obligatory.

BTW your s/boost/lslboost/ commit produced some funny results, in particular introduced the new "lslboost licence". Is it approved by FSF or OSI?

[mgrivich]

In your personal builds, you can do whatever you want. But I doubt that we will change our policy for the repository.

This is not the right thread to discuss licensing. Please make a new thread, if desired.

[mikhirev]

I'm speaking not about my personal builds but about builds for Fedora official repo.

[tstenner]

I've corrected the lslboost license name, must've missed that when renaming all the symbols.

I'd also rather use the system boost, but some third party packages (e.g. Matlab, see #227) require the boost symbols to have different names, otherwise loading the library causes crashes with unhelpful error messages.

The Fedora Packaging guidelines explicitly allow bundling libraries, you just need to contact the project publicly (done) and add a notice about the bundled libraries (Provides: bundled(libboost)=1.55).

The process to upgrade the included Boost library is quite simple and automated (see update_lslboost.sh) so it's possible to do it in a package build script with the system boost sources. With the next stable release, you can also build against a bundled subset of Boost 1.67 so you don't have to worry about outdated libraries.

[mikhirev]

@tstenner thank you, I know about these guidelines. It clearly indicates that bundling should be avoided if possible, so I'll see what to do after the new version will be released. But the best for me would be the option to use system libraries. Troubles like #227 never occurs in linux distros exactly because they link everything to the only library version.

But anyway this issue is about another problem. You are using obsolete API and, as I can see, nothing changed in master here. So I hope that my patch will be useful for you, if you are going to switch to new boost version.

[tstenner]

It's unavoidable, as liblsl can't contain plain boost symbols. Most programs need to be rebuilt on boost upgrades anyway, so you could always use the provided scripts to extract a subset of the system boost libraries and build against them.

The "obsolete" API is the only API in Boost 1.66, so Fedora (and maybe Arch and Gentoo) are the only distributions that ship the new API and even they have a configuration macro to enable the old API. Most labs still use Ubuntu 16.04, so I don't see liblsl switching to the new Asio API before 2021.

[tstenner]

Apart from that, I'll gladly accept PRs to make packaging easier. I push most of my work for Debian to the split up repos and merge back the changes from time to time, so you should send your PRs to these repos.