[pkg-boost-devel] Bug#248674: Boost and pkg-config support
ghost at cs.msu.su
Tue Mar 1 07:17:36 UTC 2011
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".
> 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?
More information about the pkg-boost-devel