From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-10 03:17:44
> > I would appreciate if folks who had problems with library order
> > previously try the current CVS state. It would be necessary to rebuilt
> > bjam, also.
> Sorry for the late review of this, had a few other projects to wrap up
> before I could devote some time to this.
> Current CVS state seems broken; unix.jam needs to "import order ;" for
> it to work:
It seems like presense of "import order" in gcc.jam has masked this problem in
my testing. Should be fixed now.
> Once this is corrected, there seems to be a problem using the new code
> with prebuilt targets, as demonstrated in the following Jamfile:
> The usage-requirement isn't being processed properly, adding an extra
> target to the link line:
> $ bjam
> ...found 10 targets...
> ...updating 1 target...
> sun.link bin/sun/debug/foo
> ild: (bad file) argument file doesn't exist::<l./sun/debug>libnsl
> "/opt/SUNWspro/bin/CC" -g -o "bin/sun/debug/foo"
> "bin/sun/debug/foo.o" "<l./sun/debug>libnsl" -Bdynamic -lnsl -lsocket
> -Bstatic -Bdynamic
The strange thing is that it works with gcc. Eh... I see the following in
flags sun.link LIBRARIES <library> ;
I think that's the bug. The <library> feature is processed specially: some
libraries are added to sources and some (exactly, searched), are represeted
as <find_shared_library> feature. The code above adds all <library> values to
LIBRARY varaible which is then added to sources.
BTW, gcc.jam has
flags sun.link LIBRARIES <library-file> ;
instead. Maybe you change change <library> to <library-file> and report the
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk