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