From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-27 16:54:53
----- Original Message -----
From: "Toon Knapen" <toon.knapen_at_[hidden]>
> >>Also NEEDLIBS is used twice to workaround circular dependency problems
> >>(as you state in the comments). Is this really necessary.
> > It certainly can be neccessary.
> >>Storing the
> >>content of <find-library> in another variable, say FINDLIBRARY and
> >>replacing the last of both NEEDLIBS in the link-line with FINDLIBRARY,
> >>every still works and it seems like a better solution to me.
> > Why? I have no axe to grind about the names (NEEDLIBS was inherited from
> > Perforce Jam), but why do you want to change it? Showing me code would
> > help.
> It would be a workaround for the first problem (external libs at the end
> of the link line). But as these will be added at the end, there's no
> need anymore.
OK. I guess I still don't understand why you thought it would be better to
have both FINDLIBRARY /and/ NEEDLIBS, but if you are satisfied I won't press
> > I didn't need to discuss it here, since it's something I've experienced
> > repeatedly using GNU linkers in the past.
> The reason I brought it up is that this 'trick' is often used to link
> libraries with circular dependencies which is bad style (to circumvent
> the left to right symbol resolution scheme for static libraries). So if
> the build systems always performs the 'trick', programmers are not going
> to try to avoid circular dependencies.
> But I guess you've experienced problems using dynamic libraries ?
That's not really the issue.
1. Sometimes one library will depend on another, even when there's no
2. With a declarative system like Boost.Build, it can be difficult for the
user to control the order in which libraries will appear on the link line.
3. Even if they can control the order, why make them think about it? Isn't
it better just to link reliably?
David Abrahams, C++ library designer for hire
C++ Booster (http://www.boost.org)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk