Subject: Re: [boost] <build>no in common properties
From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2008-12-15 11:55:13
On Dec 15, 2008, at 9:09 AM, Vladimir Prus wrote:
> K. Noel Belcourt wrote:
>> On Dec 14, 2008, at 11:01 PM, Vladimir Prus wrote:
>>> K. Noel Belcourt wrote:
>>>>>> Adding this flag generates significantly more detailed output,
>>>>>> but it
>>>>>> appears that the same libraries are still being skipped.
>>>>> Ehm. I forgot to mention that I need that detailed output -- the
>>>>> is not supposed to change the behaviour. And for avoidable of
>>>>> doubt --
>>>>> it's best to get the output for a single test.
>>>> Log for algorithm/minmax/test is attached.
>>> Are you explicitling specifying runtime-link=static somewhere? If
>>> so, why?
>> Yes. A change in the intel-11.0 compilers causes massive test
>> failures when runtime-link=shared, so I thought I'd try runtime-
>> link=static to see if I could get the intel-11.0 tests working.
>> With runtime-link=shared, all the tests fail to run because they
>> can't find one or more intel runtime libraries. The documentation is
>> clear the DYLD_LIBRARY_PATH must be set.
>> Causes Intel-provided libraries to be linked in
>> Architectures: IA-32, Intel(R) 64, IA-64 architectures
>> OFF Intel libraries are linked in
>> cally, with the exception of
>> libguide on
>> Linux* and Mac OS* X systems,
>> where it
>> is linked in dynamically.
>> This option causes Intel-provided libraries to be
>> in dynamically. It is the opposite of -static-intel.
>> NOTE: On Mac OS X systems, when you set "Intel
>> Libraries" to "Dynamic", you must also set
>> DYLD_LIBRARY_PATH environment variable within Xcode
>> or an
>> error will be displayed.
>> But the tests all fail for errors like this.
>> dyld: Library not loaded: libintlc.dylib
>> Referenced from: /private/tmp/kbelco/boost/results/boost/bin.v2/
>> Reason: Incompatible library version: multi_index_container
>> requires version 1.0.0 or later, but libintlc.dylib provides version
>> Even though my environment has DYLD_LIBRARY_PATH set correctly.
>> It seems like there's a bug in testing.jam that fails to pick up and
>> use the users environment prior to running the tests. As I said,
>> this is a change in behavior with intel-11.0
> If you edit testing.jam, run-path-setup function so that this block:
> PATH_SETUP on $(target) = [ common.prepend-path-variable-
> [ os.shared-library-path-variable ] : $(dll-paths) ] ;
> is commented out, does this improve things for runtime-link=shared?
We had a configuration problem with runtime-link=shared and
intel-11.0. Seems like the user's environment is getting picked up
okay. Thanks for the help Volodya!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk