[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: List of FTBFS in Ubuntu

Hi Roger,

On Fri, Dec 3, 2010 at 12:08 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> This is a bug in your package, unfortunately.  While it might appear
> that you only use boost_system /indirectly/, your code is in fact
> using it /directly/ via inline functions in the boost_filesystem
> headers.  You can see this for yourself if you take a close look
> at the boost_filesystem headers.

We do end up with boost::system symbols, I know that (please read the
aforementioned BTS discussion). I disagree on it being a bug on btag,
though. Please read on.

> While I do find this a rather annoying violation of encapsulation,
> you will find (e.g. with "nm -C -D") your binary will have
> boost::system symbols in it which are only satisfied indirectly
> via libboost_filesystem and which would result in breakage if
> libboost_filesystem drops that dependency and you don't explicitly
> link against it.  Ideally, the headers should be fixed.

The thing is, libboost_filesystem is not supposed to drop their
dependency on libboost_system unless its headers no longer refer to
boost::system. The requirement of linking to boost::system is an
implementation detail of boost::filesystem that package maintainers
should *not* have to worry about.

Boost works on the assumption that the linker will consider the
dependencies of the DSOs. You can say it's a Boost bug, you can say
it's a binutils-gold bug (for changing a behavior that people relied
on for the sake of performance), or you can say it's a
CMake/pkg-config bug (for not listing the right dependencies for
boost::filesystem), but it's in no way a bug in btag or any other
package that links against libboost::filesystem, libboost::asio and
countless other C++ libraries in the same situation.

So I think it would be *really* nasty if ever developer had to work
around a bug somewhere because something else is broken.


Reply to: