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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
