Re: [jamboost] Need Help w/Prebuilt Targets and Include Path

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2004-12-09 10:04:53

OK, thanks. It works (mostly) now. I must have mistyped something in
my Jamfile before but now the include paths are being picked up
properly.

I have a handful of additional questions now that I'm up and running,
if this is the correct forum. Here goes:

1. I am now building my library from four separate targets, one of
which introduces the log4cplus dependency. When this lib is being
built, the compiler is being invoked with "-llog4cplus" but no -L
flags to find it. I have this as my log4cplus target:

lib log4cplus
:
: <search>/home/eqdev/tools/linux-i686-gcc/log4cplus-1.0/lib
:
: <include>/home/eqdev/tools/linux-i686-gcc/log4cplus-1.0/include
;

The <include> part seems to be working fine, and I would expect
<search> to be the linker analog to <include> (e.g. setting -L instead
of -I) but thats not happening:

gcc.link.dll bin/gcc/debug/threading-multi/ported.so
/usr/bin/ld: cannot find -llog4cplus
collect2: ld returned 1 exit status

"g++" -o "bin/gcc/debug/threading-multi/ported.so" -Wl,-h
-Wl,ported.so -shared "bin/gcc/debug/threading-multi/BASBasic.o"
"bin/gcc/debug/threading-multi/BASBitSet.o"
"bin/gcc/debug/threading-multi/BASConfig.o"
"bin/gcc/debug/threading-multi/BASFile.o"
"bin/gcc/debug/threading-multi/BASFileBlock.o"
"bin/gcc/debug/threading-multi/BASFormatter.o"
"bin/gcc/debug/threading-multi/BASGuard.o"
"bin/gcc/debug/threading-multi/BASMMapFile.o"
"bin/gcc/debug/threading-multi/BASParser.o"
"bin/gcc/debug/threading-multi/BASPortedUtil.o"
"bin/gcc/debug/threading-multi/BASProcess.o"
"bin/gcc/debug/threading-multi/BASRegistry.o"
"bin/gcc/debug/threading-multi/BASSigHandler.o"
"bin/gcc/debug/threading-multi/BASThread.o"
"bin/gcc/debug/threading-multi/BASThreadSpecific.o"
"bin/gcc/debug/threading-multi/BASTime.o"
"bin/gcc/debug/threading-multi/BASTimer.o"
"bin/gcc/debug/threading-multi/BASTimerManager.o"
"bin/gcc/debug/threading-multi/BASDiagnostics.o" -llog4cplus -lrt 
-g -pthread

2. The current BBV2 doesn't seem to support versioned shared libraries
correctly. Taking a cue from example/versioned/jamfile.jam, I have:

lib libported : [ glob ported/src/*.cpp ] : <version>1.0 ;

But the linker is invoked with "-Wl,-h -Wl,libported.so" and not
"libported.so.1.0" which I would expect.

3. The FAQ discusses an indirect method of collecting program output
for setting properties. I'd like to be able to run an external
command to set variables in a Jamfile however. Specifically, I'd
really like build-dir to contain some indication of what platform the
build is for, so I can build using gcc on SunOS and Linux in the same
tree without them stomping on each other. Is there some simple way to
do this (e.g. an existing variable I can use without needing to run
'uname'). If not, is the moral equivalent of GNU make's $(shell) ever
likely to be added to Boost.Build?

-- 
Caleb Epstein
caleb dot epstein at gmail dot com