Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-20 08:15:40

Jürgen Hunold wrote:

>>Thanks for trying!
> You're welcome. Well, the point is that I think bjam V2 will be superior
> to qmake. And I'm happy to contribute a little to the develop.

Nice to hear that.

>>>The answer is to hadrcode the library with -Wl,-rpath, for gcc.
>> > Another change is to link against qt-mt (Multi-Thread).
>> > I wonder about detecting this somehow...
>>What should be detected? The need to -Wl,-rpath, or multitheaded QT?
> Well, hardcoding the library-path is always good, at least for
> development. I guess this should either be made default or a
> configuration switch.

The current situation is:
1. All libraries are shared by default
2. -rpath is not passed

However, there's "hardcode-dll-paths" property. When it's set, for each linked
executable, paths for each library is added to -rpath. For example, if you
go to examples-v2/libraries and run

bjam hardcode-dll-paths=true

there, then you'll be able to run


without adjusting LD_LIBRARY_PATH.

> Multithreaded Qt depends on a multithreaded configuration. The qt
> toolset should select qt-mt depending on the feature <threading>multi.
> So no autodetect is needed.


>>>BTW, how do I link against external libraries ? I would need
>>>STLport i order to test with something real ? I've tried to figure
>>>out something from boost.python Jamfile.v2, but did not succeed.
>>Oh... well... that's undocumented. Let me try to explain this in
>>email. I'll add it to docs after that.
>>Is this explanation appropriate?
> I'll try out later. Maybe this evening I fear. Have to get some work
> done...


- Volodya


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