Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-23 09:37:07

Felix E. Klee wrote:

>>>As you see, I didn't use "-lqt" because that doesn't work. According to
>>>the bc++ documentation, "-l" does something else:
>>Eh... does that exactly ""? Is that library searched in -L path? Or
>>it should be present in "."?
> It finds the library in the -L path. BTW, Here's the corresponding line from
> Boost Build v1:
> actions kylix-Link-action
> {
> "$(BCC_TOOL_PATH)bc++" -v -q $(LINKFLAGS) -L"$(LIBPATH)"
> -L"$(STDLIBPATH)" -o"$(<[1])" "$(>)" lib$(FINDLIBS).so
> }


> Here again, the comlete file name is specified. One big problem that comes
> into my mind is that such a link action will fail when only a static version
> of a library is available. But that just seems to be the Kylix way: when one
> wants to add a library in the IDE one has to specify the complete path name.
> There seems to be no way to specify just the library base name and let Kylix
> do the rest.

Yes, I've noted that too. Looks like shared/static linkage should be
explicitly specified.

> I just did a little static library test that consists of
> - A static libary ~/projects/kylix-lib-test/bar.a created in the IDE.
> - A console application ~/projects/kylix-test/foo created in the IDE.
> Results:
> 1. The linker command line generated by the IDE, of course, works:
> ilink [...] -L[...]/net/hubble/Users/felix/projects/kylix-lib-test \
> borinit.o crt1.o foo.o, foo,, ../kylix-lib-test/bar.a libborcrtl.a \
> libborstl.a libborunwind.a, , foo.res
> Note that bar.a is specified with a path relative to the current directory.
> 2. Removing the relative path doesn't work:
> ilink [...] -L[...]:/net/hubble/Users/felix/projects/kylix-lib-test \
> borinit.o crt1.o foo.o, foo,, bar.a libborcrtl.a \
> libborstl.a libborunwind.a, , foo.res
> =>
> Fatal: Unable to open file 'bar.a'
> Hm, that's unlike to what's printed in the documentation. It seems to be
> another ilink bug or a Kylix documentation bug. Weirdly though, ilink finds
> libborstl.a, etc..

Ick! What does it say if you specify "libbar.a" in the linker commnad line
(but don't change the name of the actual library?)

> 3. Specifying instead of bar.a doesn't work either:
> ilink [...] -L[...]:/net/hubble/Users/felix/projects/kylix-lib-test \
> borinit.o crt1.o foo.o, foo,, libborcrtl.a \
> libborstl.a libborunwind.a, , foo.res
> =>
> Fatal: Unable to open file ''
> That's unlike the bavior of ld where a static lib is used instead of the
> corresponding shared lib if that can't be found. But at least this seems to
> be consistent with the documentation where I couldn't find the mentioning
> of such a feature.


> BTW, you might have noticed that the library is called "foo.a", not
> "libfoo.a". This seems to be common in Kylix, eg. static libraries mentioned
> in the documentation often don't have the lib prefix. But just to make sure
> that this is not the cause of all the trouble, I repeated the above tests
> with libbar.a (a symlink to bar.a) and got the same results.
> Conclusion:
> 1. Static libraries created by the user or third party libraries need to be
> specified with their complete path.

Static libraries which are created by Boost.Build will be linked by complete
path already. About third parties: this looks very strange. Probably they
really should have written better docs ;-)

> 2. Shared libraries only need to be specified with their complete name if -L
> is properly set, specifying the entire path is not neccessary.

OK, that's reasonable.

>>In either case, I've made the changes to get both "-L" and ""
>>into bc++ command line. Could you please test again?
> Yes, it works now. However, I had to change qt-mt into qt in new/qt.jam since
> I didn't try to compile the multi threaded QT library for Kylix yet.
> Shouldn't qt be the default and only be changed to qt-mt when <threading> is
> set to multi?

You've right! Care to try fixing that? The add-properties rule in qt.jam is
the key: just compute the library name depending on whether <theading>multi is
in properties.

> I plan to apply Boost Build v2 to a little project consisting of a couple of
> libraries and an executable. If that works with bc++ as a link action, I guess
> there is no reason to change it to ilink for now.

Okay, I'm waiting for your experience.

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at