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