Re: [jamboost] Toolset inheritance, Kylix

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 "libqt.so"? 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
> {
> export PATH=$(BCC_TOOL_PATH):$PATH
> "$(BCC_TOOL_PATH)bc++" -v -q $(LINKFLAGS) -L"$(LIBPATH)"
> -L"$(STDLIBPATH)" -o"$(<[1])" "$(>)" lib$(FINDLIBS).so
> }

OK.

> 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 libc.so libm.so libdl.so, , 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 libc.so libm.so libdl.so, , 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 bar.so 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,, bar.so libborcrtl.a \
> libborstl.a libborunwind.a libc.so libm.so libdl.so, , foo.res
> =>
> Fatal: Unable to open file 'bar.so'
> 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.

OK.

> 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 "libqt-mt.so"
>>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