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
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
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