Re: List of FTBFS in Ubuntu
Hi Roger,
On Fri, Dec 3, 2010 at 3:41 PM, Roger Leigh <rleigh@codelibre.net> wrote:
[...]
> btag *does* use boost::system, even though you don't want to use it.
> Right now, with the g++4.5 and/or the gold linker, you aren't linking
> with a library you need. And I'm afraid that right at this point in
> time, it does need solving in btag.
>From the compiler perspective, it does use boost::System. From the
developer perspective, it doesn't. Sure, I can patch the build system
to include -lboost_system, but what if Boost 1.4.3 depends on another
library? It's madness, this doesn't scale at all.
> Now arguably, boost should provide that information for use, but
> right now it *doesn't*, and it is the user's responsibility to do
> the donkey work. This information isn't specified in the library
> dependencies, so they can't be used as a substitute.
Their reasoning I think is that the dependency is already encoded in
the DSOs, no need to make that information redundant. If they did
provide this info, I'd agree on following it to the letter and adding
that dependency information to the build system.
> Why? If you link indirectly today, and later on boost_filesystem
> drops its boost_system dependency, your code will break because
> those inlined functions are in *your* code, not the filesystem
> library. You'll get a link failure. By linking explictly, you're
> protected against future failure.
I don't disagree, though as I said previously, if boost::filesystem
dropped the libboost_system dependency, it's because it's no longer
present in the headers too, so that wouldn't be an issue. If they drop
it and still use in the headers, then it's likely going to be
considered a bug.
> Just for the record, C++ templates don't require inlining; you can
> specifically instantiate and export particular instances to avoid
> this. Full support for exported templates in g++ would also be
> useful, but we've been waiting over a decade for that and it's due to
> be removed from the standard.
I think it would require some refactoring in Boost.
>> So I think it would be *really* nasty if ever developer had to work
>> around a bug somewhere because something else is broken.
>
> It's arguable whether it's a bug or not. Maybe this is what was
> specifically intended? We do need a scalable approach to dealing
> with this, and I'd suggest pkg-config should be the route to take.
> But until such time we have a solution like that in place, the
> onus is on the library users to link correctly, and it is going
> to be a major problem.
How about this compromise. If --add-needed worked with binutils-gold,
Boost projects could specify it and keep depending only on the libs
they actually use (from a developer's perspective). I'd be happy to
add that flag upstream in btag.
Regards,
Reply to: