Re: [boost] Boost and pkg-config support

Subject: Re: [boost] Boost and pkg-config support
From: Vladimir Prus (ghost_at_[hidden])
Date: 2011-03-01 06:41:04

On Tuesday, March 01, 2011 14:21:54 Roger Leigh wrote:
> On Tue, Mar 01, 2011 at 11:08:14AM +0300, Vladimir Prus wrote:
> > On Tuesday, March 01, 2011 10:52:35 Steve M. Robbins wrote:
> > > On Tue, Mar 01, 2011 at 10:17:36AM +0300, Vladimir Prus wrote:
> > > > Could you brief me on what's --as-needed, why is it needed, and why
> > > > does it break a perfect model of "I link to shared library foo, and
> > > > whatever dependecies are used automatically".
> > > 
> > > The rationale (from http://wiki.debian.org/ToolChain/DSOLinking)
> > > is to detect situations where
> > > 
> > >     your executable links against a library A which links against
> > >     library B, but your executable needs symbols in library B. This is
> > >     problematic in the situation where library A removes its
> > >     dependency to library B. The next time the executable gets rebuild
> > >     it will break and cannot be linked.
> > 
> > <sarcasm>Oh, welcome to this new world where linking on Unix works just
> > line in Windows</sarcasm>
> > 
> > Seriously, though:
> > 
> > 1. It appears --as-needed has nothing to do with this issue. It is
> > --no-copy-dt-needed-entries that breaks things.
> 
> Yes.  This is the crux of the problem: in the absence of implicit
> indirect linking, we are forced to explicitly link with every library
> we need and we need some mechanism to inform us which ones to link
> with.  This is annoying, but as the link above details, there are good
> reasons for doing this.
> 
> > 2. I agree that pkg-config is the only possible solution.
> > 
> > 3. I am not much of pkg-config expert; and Boost.Build's interpreted
> > language is really not much harder than any of other languages present
> > on Unix. So, the fastest way for this to be fixed is for me to sketch up
> > Boost.Build code and then have somebody fill in the blanks and actually
> > test it.
> 
> If Boost.Build can be used to get the information to generate the
> pkg-config .pc files, that would be great.  If this can all be done
> during the boost build, that would be even better.  Out of interest,
> where does Boost.Build get the information from, if not from
> auto-link information?  Is the information duplicated elsewhere?

Well, gcc has no autolink, so for static linking to work, Boost.Build has to
know that boost.filesystem depends on boost.system, and this information is
directly present in boost.filesystem's Jamfile.

> For the patch I mentioned in my initial mail, this just needs building
> and running in a loop, such as (pseudocode)
> 
> for (header+library name in each of boost's libraries) {
>   compile with PREFIX=prefix LIBDIR=libdir TEST_HEADER=header
> TEST_LIBRARY=library link with all boost libraries
>   run to autogenerate header > library.pc (e.g. boost_program_options.pc)
> }

As you've mentioned yourself, this approach won't work very well for cross-compilation.

Also -- we still get the question from the original issue -- what shall we do
if building multiple variants together with decorated names? Use the same 
decoration for .pc files as we do for library files?

- Volodya