Debian Bug report logs - #248674
libboost-dev: please provide a pkg-config file

Package: boost-defaults; Maintainer for boost-defaults is Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>;

Reported by: martin f krafft <madduck@debian.org>

Date: Wed, 12 May 2004 18:18:02 UTC

Severity: wishlist

Tags: patch

Merged with 350539

Forwarded to https://svn.boost.org/trac/boost/ticket/1094

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, smr@debian.org (Steve M. Robbins):
Bug#248674; Package libboost-dev. Full text and rfc822 format available.

Acknowledgement sent to martin f krafft <madduck@debian.org>:
New Bug report received and forwarded. Copy sent to smr@debian.org (Steve M. Robbins). Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libboost-dev: please provide a pkg-config file
Date: Wed, 12 May 2004 20:16:47 +0200
[Message part 1 (text/plain, inline)]
Package: libboost-dev
Version: 1.31.0-4
Severity: wishlist
Tags: patch

It would be nice if libboost could provide a pkgconfig file. The
following would suffice:

  prefix=/usr
  exec_prefix=${prefix}
  libdir=${exec_prefix}/lib
  includedir=${prefix}/include

  Name: libboost
  Description: The boost.org C++ library collection
  Version: 1.31.0
  Libs: -L${libdir}
  Cflags: -I${includedir}

Of course, you may want to use m4 or autoconf to control the prefix
and version entries...

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (600, 'testing'), (98, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.3-1-k7-smp
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=de_DE.ISO-8859-15

Versions of packages libboost-dev depends on:
ii  libboost-python-dev           1.31.0-4   The Boost Python Library developme
ii  libstdc++5-3.3-dev [libstdc++ 1:3.3.3-6  The GNU Standard C++ Library v3 (d

-- no debconf information

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, smr@debian.org (Steve M. Robbins):
Bug#248674; Package libboost-dev. Full text and rfc822 format available.

Acknowledgement sent to "Steve M. Robbins" <steven.robbins@videotron.ca>:
Extra info received and forwarded to list. Copy sent to smr@debian.org (Steve M. Robbins). Full text and rfc822 format available.

Message #10 received at 248674@bugs.debian.org (full text, mbox):

From: "Steve M. Robbins" <steven.robbins@videotron.ca>
To: martin f krafft <madduck@debian.org>, 248674@bugs.debian.org
Subject: Re: Bug#248674: libboost-dev: please provide a pkg-config file
Date: Wed, 12 May 2004 21:50:03 -0400
Hello Martin,

That's an interesting suggestion.  I don't know much about pkg-config.
Could you elaborate a bit on the general advantages of providing one?
What is it used for?

In particular, since the proposed Libs and Cflags settings 

On Wed, May 12, 2004 at 08:16:47PM +0200, martin f krafft wrote:

>   prefix=/usr
>   exec_prefix=${prefix}
>   libdir=${exec_prefix}/lib
>   includedir=${prefix}/include
> 
>   Name: libboost
>   Description: The boost.org C++ library collection
>   Version: 1.31.0
>   Libs: -L${libdir}
>   Cflags: -I${includedir}

are already on the compiler and linker search paths, what
is the point?

Thanks,
-Steve




Information forwarded to debian-bugs-dist@lists.debian.org, smr@debian.org (Steve M. Robbins):
Bug#248674; Package libboost-dev. Full text and rfc822 format available.

Acknowledgement sent to martin f krafft <madduck@debian.org>:
Extra info received and forwarded to list. Copy sent to smr@debian.org (Steve M. Robbins). Full text and rfc822 format available.

Message #15 received at 248674@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: "Steve M. Robbins" <steven.robbins@videotron.ca>
Cc: 248674@bugs.debian.org
Subject: Re: Bug#248674: libboost-dev: please provide a pkg-config file
Date: Thu, 13 May 2004 12:52:02 +0200
[Message part 1 (text/plain, inline)]
also sprach Steve M. Robbins <steven.robbins@videotron.ca> [2004.05.13.0350 +0200]:
> In particular, since the proposed Libs and Cflags settings 
> are already on the compiler and linker search paths, what
> is the point?

Well, there are two basic advantages:

  (a) autoconf checking for library presence
  (b) ability to install somewhere else than /usr

(b) is not so important with Debian, thus it would be nice if the
pkgconfig files made it upstream.

(a), however, is important and requires some thought since
libboost-dev is a collection of multiple libraries. If I want to
write a program that only needs, e.g. boost::random, then I should
have an easy way to check for presence of that library without
checking for $prefix/usr/include/boost/random.hpp. Thus, I think
the boost libraries should install one pkdconfig file each.
libboost-dev would then install a number of them.

They do seem redundant, but they are becoming the standard and it
doesn't hurt to have them, does it?

With pkgconfig files, e.g. I could install libboost-dev normally and
then download the CVS version of boost::random and install into
/usr/local. Then I could tell my ./configure script to use those
quite easily.

Does this make sense?

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, smr@debian.org (Steve M. Robbins):
Bug#248674; Package libboost-dev. Full text and rfc822 format available.

Acknowledgement sent to "Steve M. Robbins" <steven.robbins@videotron.ca>:
Extra info received and forwarded to list. Copy sent to smr@debian.org (Steve M. Robbins). Full text and rfc822 format available.

Message #20 received at 248674@bugs.debian.org (full text, mbox):

From: "Steve M. Robbins" <steven.robbins@videotron.ca>
To: martin f krafft <madduck@debian.org>
Cc: 248674@bugs.debian.org
Subject: Re: Bug#248674: libboost-dev: please provide a pkg-config file
Date: Sun, 16 May 2004 01:35:11 -0400
Hi Martin,

From what you say, it makes more sense to get pkgconfig put into
upstream.

On Thu, May 13, 2004 at 12:52:02PM +0200, martin f krafft wrote:
> also sprach Steve M. Robbins <steven.robbins@videotron.ca> [2004.05.13.0350 +0200]:
> > In particular, since the proposed Libs and Cflags settings 
> > are already on the compiler and linker search paths, what
> > is the point?
> 
> Well, there are two basic advantages:
> 
>   (a) autoconf checking for library presence
>   (b) ability to install somewhere else than /usr
> 
> (b) is not so important with Debian, thus it would be nice if the
> pkgconfig files made it upstream.
> 
> (a), however, is important and requires some thought since
> libboost-dev is a collection of multiple libraries. If I want to
> write a program that only needs, e.g. boost::random, then I should
> have an easy way to check for presence of that library without
> checking for $prefix/usr/include/boost/random.hpp.

When using autoconf, rather than checking for a header file in a
specific location in the file system, one typically tries to compile a
test program that would #include <boost/random.hpp>.  I don't see how
a pkgconfig file would make any difference.


> With pkgconfig files, e.g. I could install libboost-dev normally and
> then download the CVS version of boost::random and install into
> /usr/local. Then I could tell my ./configure script to use those
> quite easily.

Sorry for being dense, but how does a pkgconfig file help you
in this situation?

 
> Does this make sense?

Not to me.  Not yet, at least.

-Steve



Reply sent to martin f krafft <madduck@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to martin f krafft <madduck@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #25 received at 248674-done@bugs.debian.org (full text, mbox):

From: martin f krafft <madduck@debian.org>
To: "Steve M. Robbins" <steven.robbins@videotron.ca>
Cc: 248674-done@bugs.debian.org
Subject: Re: Bug#248674: libboost-dev: please provide a pkg-config file
Date: Sun, 16 May 2004 12:09:42 +0200
[Message part 1 (text/plain, inline)]
also sprach Steve M. Robbins <steven.robbins@videotron.ca> [2004.05.16.0735 +0200]:
> Sorry for being dense, but how does a pkgconfig file help you in
> this situation?

I understand that it doesn't make full sense, and neither am I sure
anymore. I just like pkgconfig, because it allows me to automate
handling of multiple installed version, which is rather nice during
development. However, with libboost-dev being a toolbox really, I am
not sure it makes sense -- especially because Debian's libboost-dev
is a quasi-random collection of boost libraries. With that, I don't
mean to dizz the package or you, I am just saying that there exists
no collection at boost.org which you packaged, but rather, you
put basically whatever was left over into libboost-devel.

Note that I am closing the bug as I can't find arguments to convince
you. And we don't need to argue just for the sake of it. When
I wrote the bug, pkgconfig was *the* solution. Now I am not sure
anymore.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
[signature.asc (application/pgp-signature, inline)]

Bug unarchived. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Sun, 05 Dec 2010 00:33:02 GMT) Full text and rfc822 format available.

Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 05 Dec 2010 00:33:02 GMT) Full text and rfc822 format available.

Bug reassigned from package 'libboost-dev' to 'boost1.44'. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Sun, 05 Dec 2010 00:33:02 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions 1.31.0-4. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Sun, 05 Dec 2010 00:33:03 GMT) Full text and rfc822 format available.

Set Bug forwarded-to-address to 'https://svn.boost.org/trac/boost/ticket/1094'. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Sun, 05 Dec 2010 00:33:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost1.44. (Sun, 05 Dec 2010 00:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Sun, 05 Dec 2010 00:48:03 GMT) Full text and rfc822 format available.

Message #40 received at 248674@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: control@bugs.debian.org
Cc: "Steve M. Robbins" <steve@sumost.ca>, martin f krafft <madduck@debian.org>
Subject: Re: Bug#248674: libboost-dev: please provide a pkg-config file
Date: Sun, 5 Dec 2010 00:22:09 +0000
[Message part 1 (text/plain, inline)]
reopen 248674
reassign 248674 boost1.44
forwarded 248674 https://svn.boost.org/trac/boost/ticket/1094
tags 248674 + patch
thanks

Hi Steve,

Given #593876 and recent other bugs and discussion on debian-devel,
regarding issues with boost linking with upcoming compiler changes,
pkg-config looks like it will be the best solution to the problems
in the long term.

I've spent this weekend writing a patch to the long standing
upstream request for pkg-config support in Boost, and hopefully
we'll get somewhere now we have a working patch for this.  Reopening
the Debian bug to track this.

The patch isn't totally complete.  The bits work, but I lack the
bjam knowhow to integrate it nicely into the Boost build system.


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.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, unknown-package@qa.debian.org:
Bug#248674; Package boost1.44. (Sun, 27 Feb 2011 20:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to unknown-package@qa.debian.org. (Sun, 27 Feb 2011 20:06:03 GMT) Full text and rfc822 format available.

Message #45 received at 248674@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: "Steve M. Robbins" <steve@sumost.ca>, VladimirPrusghost@cs.msu.su
Cc: 248674@bugs.debian.org
Subject: Boost and pkg-config support
Date: Sun, 27 Feb 2011 20:04:56 +0000
[Message part 1 (text/plain, inline)]
Hi Steve and Vladimir,

I know you're both really busy, so if you haven't got time for this
right now, don't worry.  However, this is becoming increasingly
important.  It was previously a nice to have; with new GCCs, it's
going to become rather more essential if one wishes to have any
hope of proper linking and support more than one Boost release.

With --as-needed in GCC making linking much stricter, knowing
which Boost libraries need linking in is becoming much more of
an issue, especially since you can't rely on indirect linking
doing the right thing.  You are required to know *all* the libraries
you need to link with in advance--and this can change with Boost
versions, and we have no hope of being able to do this reliably without
the same level of support that auto-linking provides Windows users with
suitable compilers.

https://svn.boost.org/trac/boost/ticket/1094
is the upstream ticket for adding pkg-config support.  I've already
done the bulk of the work, the patches are all there.  Do you have
any knowledge of bjam?  I don't, and the missing part is integrating
the patch with the build system.  This is probably trivial if you
have any idea how bjam works, but I don't have the first clue.  I had
a good look, but after several hours I'm still no wiser, so it would
probably be a much more effective use of time and effort for someone
with working bjam knowledge to do the last bit.  With the patches in
the ticket, bjam just needs telling how to spit out and install the
pkg-config .pc files.

auto-link-pkg-config.2.patch is the header patch to supply us with
the needed library dependency information.

boost-pkg-config-gen.cc is the program to acquire the information
and generate the .pc file.  It just needs building with these defines:
  TEST_HEADER - the header to include for a given boost library
  PREFIX - the bjam prefix (however you get at it)
  LIBDIR - the bjam libdir (however you get at it)
So the program just needs building and running once for each Boost
library (bjam must have a list of libraries, or at least provide some
means for us to get at the information).  Then those files just need
installing in $prefix/lib/pkgconfig and the job is done.  If you wish
to support cross-compiling, this could be done by a script post-install.
For distributions like Debian where we compile natively, that's not a
major issue at present, so we could like without cross-compile support.

Users can then just run e.g. "pkg-config --libs boost_filesystem" and
it will tell them exactly which libs are required (or they can use
the autoconf macros to do this automatically).

Even if you don't include the tools directly in Boost, having the
header patch in place will at least allow others to create such tools.


Many thanks,
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.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, unknown-package@qa.debian.org:
Bug#248674; Package boost1.44. (Sun, 27 Feb 2011 20:12:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to unknown-package@qa.debian.org. (Sun, 27 Feb 2011 20:12:09 GMT) Full text and rfc822 format available.

Message #50 received at 248674@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: "Steve M. Robbins" <steve@sumost.ca>, Vladimir Prus <ghost@cs.msu.su>
Cc: 248674@bugs.debian.org
Subject: Boost and pkg-config support
Date: Sun, 27 Feb 2011 20:08:42 +0000
[Message part 1 (text/plain, inline)]
Hi Steve and Vladimir,

I know you're both really busy, so if you haven't got time for this
right now, don't worry.  However, this is becoming increasingly
important.  It was previously a nice to have; with new GCCs, it's
going to become rather more essential if one wishes to have any
hope of proper linking and support more than one Boost release.

With --as-needed in GCC making linking much stricter, knowing
which Boost libraries need linking in is becoming much more of
an issue, especially since you can't rely on indirect linking
doing the right thing.  You are required to know *all* the libraries
you need to link with in advance--and this can change with Boost
versions, and we have no hope of being able to do this reliably without
the same level of support that auto-linking provides Windows users with
suitable compilers.

https://svn.boost.org/trac/boost/ticket/1094
is the upstream ticket for adding pkg-config support.  I've already
done the bulk of the work, the patches are all there.  Do you have
any knowledge of bjam?  I don't, and the missing part is integrating
the patch with the build system.  This is probably trivial if you
have any idea how bjam works, but I don't have the first clue.  I had
a good look, but after several hours I'm still no wiser, so it would
probably be a much more effective use of time and effort for someone
with working bjam knowledge to do the last bit.  With the patches in
the ticket, bjam just needs telling how to spit out and install the
pkg-config .pc files.

auto-link-pkg-config.2.patch is the header patch to supply us with
the needed library dependency information.

boost-pkg-config-gen.cc is the program to acquire the information
and generate the .pc file.  It just needs building with these defines:
  TEST_HEADER - the header to include for a given boost library
  PREFIX - the bjam prefix (however you get at it)
  LIBDIR - the bjam libdir (however you get at it)
So the program just needs building and running once for each Boost
library (bjam must have a list of libraries, or at least provide some
means for us to get at the information).  Then those files just need
installing in $prefix/lib/pkgconfig and the job is done.  If you wish
to support cross-compiling, this could be done by a script post-install.
For distributions like Debian where we compile natively, that's not a
major issue at present, so we could like without cross-compile support.

Users can then just run e.g. "pkg-config --libs boost_filesystem" and
it will tell them exactly which libs are required (or they can use
the autoconf macros to do this automatically).

Even if you don't include the tools directly in Boost, having the
header patch in place will at least allow others to create such tools.


Many thanks,
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.
[signature.asc (application/pgp-signature, inline)]

Bug reassigned from package 'boost1.44' to 'boost-defaults'. Request was from "Steve M. Robbins" <steve@sumost.ca> to control@bugs.debian.org. (Tue, 01 Mar 2011 03:39:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost-defaults. (Tue, 01 Mar 2011 03:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Steve M. Robbins" <steve@sumost.ca>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Tue, 01 Mar 2011 03:48:03 GMT) Full text and rfc822 format available.

Message #57 received at 248674@bugs.debian.org (full text, mbox):

From: "Steve M. Robbins" <steve@sumost.ca>
To: Roger Leigh <rleigh@codelibre.net>, boost@lists.boost.org
Cc: Vladimir Prus <ghost@cs.msu.su>, 248674@bugs.debian.org
Subject: Re: Boost and pkg-config support
Date: Mon, 28 Feb 2011 21:43:56 -0600
[Message part 1 (text/plain, inline)]
Boosters, please see the following for background:

[1]  https://svn.boost.org/trac/boost/ticket/1094
[2]  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674
[3]  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593876
  

On Sun, Feb 27, 2011 at 08:08:42PM +0000, Roger Leigh wrote:

> https://svn.boost.org/trac/boost/ticket/1094
> is the upstream ticket for adding pkg-config support.  I've already
> done the bulk of the work, the patches are all there.  Do you have
> any knowledge of bjam?  

Vladimir is the bjam expert ;-)


> boost-pkg-config-gen.cc is the program to acquire the information
> and generate the .pc file.  It just needs building with these defines:
>   TEST_HEADER - the header to include for a given boost library
>   PREFIX - the bjam prefix (however you get at it)
>   LIBDIR - the bjam libdir (however you get at it)

I have spent some time trying to patch bjam and have no inclination to
spend any more time with that code.  For Debian purposes, could we
obtain PREFIX and LIBDIR directly from debian/rules?  (In fact, they
would be constants, of course).  What about TEST_HEADER?


> So the program just needs building and running once for each Boost
> library (bjam must have a list of libraries, or at least provide some
> means for us to get at the information).  

Bjam has a list of the libraries that are *compiled* to a so/dll.  Is
that enough?  The root of the problem [3] is inlined code and there's
no guarantee that a header-only library won't similarly inline
something that requires, say, -lboost_system.

Boost Developers: is there a machine readable list of libraries 
somewhere in the boost source tree?

Thanks,
-Steve
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost-defaults. (Tue, 01 Mar 2011 07:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vladimir Prus <ghost@cs.msu.su>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Tue, 01 Mar 2011 07:21:03 GMT) Full text and rfc822 format available.

Message #62 received at 248674@bugs.debian.org (full text, mbox):

From: Vladimir Prus <ghost@cs.msu.su>
To: Roger Leigh <rleigh@codelibre.net>, boost@lists.boost.org
Cc: "Steve M. Robbins" <steve@sumost.ca>, 248674@bugs.debian.org
Subject: Re: Boost and pkg-config support
Date: Tue, 1 Mar 2011 10:17:36 +0300
On Sunday, February 27, 2011 23:08:42 Roger Leigh wrote:
> Hi Steve and Vladimir,
> 
> I know you're both really busy, so if you haven't got time for this
> right now, don't worry.  However, this is becoming increasingly
> important.  It was previously a nice to have; with new GCCs, it's
> going to become rather more essential if one wishes to have any
> hope of proper linking and support more than one Boost release.
> 
> With --as-needed in GCC making linking much stricter, knowing
> which Boost libraries need linking in is becoming much more of
> an issue, especially since you can't rely on indirect linking
> doing the right thing.  You are required to know *all* the libraries
> you need to link with in advance--and this can change with Boost
> versions, and we have no hope of being able to do this reliably without
> the same level of support that auto-linking provides Windows users with
> suitable compilers.

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".

> https://svn.boost.org/trac/boost/ticket/1094
> is the upstream ticket for adding pkg-config support.  I've already
> done the bulk of the work, the patches are all there.  Do you have
> any knowledge of bjam?  I don't, and the missing part is integrating
> the patch with the build system.  This is probably trivial if you
> have any idea how bjam works, but I don't have the first clue.  I had
> a good look, but after several hours I'm still no wiser, so it would
> probably be a much more effective use of time and effort for someone
> with working bjam knowledge to do the last bit.  With the patches in
> the ticket, bjam just needs telling how to spit out and install the
> pkg-config .pc files.
> 
> auto-link-pkg-config.2.patch is the header patch to supply us with
> the needed library dependency information.
> 
> boost-pkg-config-gen.cc is the program to acquire the information
> and generate the .pc file.  It just needs building with these defines:
>   TEST_HEADER - the header to include for a given boost library
>   PREFIX - the bjam prefix (however you get at it)
>   LIBDIR - the bjam libdir (however you get at it)
> So the program just needs building and running once for each Boost
> library (bjam must have a list of libraries, or at least provide some
> means for us to get at the information).  Then those files just need
> installing in $prefix/lib/pkgconfig and the job is done.  

Oh, using autolink headers to extract dependency information is cute.

> If you wish
> to support cross-compiling, this could be done by a script post-install.

Well, this is obviously somewhat messy. Another alternative approach is
to have dependency information extracted by Boost.Build -- which obviously
knows what other libraries any given one is linked to.

However, I still would like to understand why this is becoming more important
now. For all I could tell, with our current naming scheme (without compiler
and other decoration in library name), and with dynamic linking, you should
be able to just say -lboost_whatever and it should work. What am I missing?

- Volodya




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost-defaults. (Tue, 01 Mar 2011 07:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Steve M. Robbins" <steve@sumost.ca>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Tue, 01 Mar 2011 07:57:03 GMT) Full text and rfc822 format available.

Message #67 received at 248674@bugs.debian.org (full text, mbox):

From: "Steve M. Robbins" <steve@sumost.ca>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: Roger Leigh <rleigh@codelibre.net>, boost@lists.boost.org, 248674@bugs.debian.org
Subject: Re: Boost and pkg-config support
Date: Tue, 1 Mar 2011 01:52:35 -0600
[Message part 1 (text/plain, inline)]
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.


I think that pkg-config style dependency information is also helpful
for people using static linking.

Cheers,
-Steve
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost-defaults. (Tue, 01 Mar 2011 08:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vladimir Prus <ghost@cs.msu.su>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Tue, 01 Mar 2011 08:09:03 GMT) Full text and rfc822 format available.

Message #72 received at 248674@bugs.debian.org (full text, mbox):

From: Vladimir Prus <ghost@cs.msu.su>
To: "Steve M. Robbins" <steve@sumost.ca>
Cc: Roger Leigh <rleigh@codelibre.net>, boost@lists.boost.org, 248674@bugs.debian.org
Subject: Re: Boost and pkg-config support
Date: Tue, 1 Mar 2011 11:08:14 +0300
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.

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.

- Volodya




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost-defaults. (Tue, 01 Mar 2011 11:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Tue, 01 Mar 2011 11:24:03 GMT) Full text and rfc822 format available.

Message #77 received at 248674@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: "Steve M. Robbins" <steve@sumost.ca>, boost@lists.boost.org, 248674@bugs.debian.org
Subject: Re: Boost and pkg-config support
Date: Tue, 1 Mar 2011 11:21:54 +0000
[Message part 1 (text/plain, inline)]
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@LIB1@ -l@LIB2@ -l@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.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost-defaults. (Tue, 01 Mar 2011 11:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vladimir Prus <ghost@cs.msu.su>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Tue, 01 Mar 2011 11:45:06 GMT) Full text and rfc822 format available.

Message #82 received at 248674@bugs.debian.org (full text, mbox):

From: Vladimir Prus <ghost@cs.msu.su>
To: Roger Leigh <rleigh@codelibre.net>
Cc: "Steve M. Robbins" <steve@sumost.ca>, boost@lists.boost.org, 248674@bugs.debian.org
Subject: Re: Boost and pkg-config support
Date: Tue, 1 Mar 2011 14:41:04 +0300
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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>:
Bug#248674; Package boost-defaults. (Tue, 01 Mar 2011 12:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian Boost Team <pkg-boost-devel@lists.alioth.debian.org>. (Tue, 01 Mar 2011 12:15:03 GMT) Full text and rfc822 format available.

Message #87 received at 248674@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: "Steve M. Robbins" <steve@sumost.ca>, boost@lists.boost.org, 248674@bugs.debian.org
Subject: Re: Boost and pkg-config support
Date: Tue, 1 Mar 2011 12:11:58 +0000
[Message part 1 (text/plain, inline)]
On Tue, Mar 01, 2011 at 02:41:04PM +0300, Vladimir Prus wrote:
> On Tuesday, March 01, 2011 14:21:54 Roger Leigh wrote:
> > 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?

If you're building multiple variants, you would need multiple .pc
files, one per library variant.  The same decoration would be
appropriate so they match.

At least on Linux, where we only really usually care about a single
release variant, and use it undecorated, it would be nice to have
a set of undecorated files so that you can just use e.g.
`pkg-config --libs boost_program_options` and get the system default.
If the user needs a specific variant, they could use a more specific
suffix.  These undecorated variants could be either generated by
boost, or be a set of symlinks to specific variants created by the
distributor (who would choose the default).  Steve is better qualified
to comments on the requirements here ;)

In practice, on Linux there is only one variant (two if you include
debugging symbols), so we don't really need (or want) to consider the
non-standard naming conventions used by Boost.  We have a system
default toolchain, so variants are redundant; Boost is the only project
creating such non-standard suffixes.  It's fine to create those extra
.pc files for the multiple variants, but in practice I doubt they will
be used.  In my projects, I'll be using autoconf like this:

PKG_CHECK_MODULES([BOOST_PROGRAM_OPTIONS], [boost_program_options])

and have it autodetect the system defaults.  The other variants won't
be considered.  This will cause BOOST_PROGRAM_OPTIONS_LIBS to be set to
"-lboost_program_options", and would include dependent libs in the case
of e.g. boost_filesystem.  This is the typical use case for pkg-config
files.  If there's a use case for pkg-config on Windows, I'm sure the
variants will have a use there.


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.
[signature.asc (application/pgp-signature, inline)]

Merged 248674 350539 Request was from "Steve M. Robbins" <steve@sumost.ca> to control@bugs.debian.org. (Sun, 23 Sep 2012 22:51:05 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 10:38:57 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.