[pkg-boost-devel] Bug#248674: Boost and pkg-config support

[Roger Leigh]

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?

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)
}

Which will generate a single pkg-config .pc file per header, using the
following template:

--------
prefix=@PREFIX@
exec_prefix=${prefix}
libdir=@LIBDIR@
includedir=${prefix}/include

Name: @TEST_LIBRARY@
Description: Boost C++ libraries (@TEST_LIBRARY@)
Version: @BOOST_VERSION@
Libs: -L${libdir} -l at LIB1@ -l at LIB2@ -l at LIB3@
Cflags: -I${includedir}"
--------

Everything in @CAPS@ is a substituted value.  If you wish to generate
the .pc files using some other mechanism, you can generate the files
using the same basic template.  That's really all there is to
pkg-config support.  They just need installing in $libdir/pkgconfig,
and that's it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20110301/9cdc37be/attachment.pgp>