<build>no in common properties
Hi, The Sandia-darwin-intel-11.0 results are failing because essentially every Boost product is not being built (actually being skipped). This message is present for almost every Boost library. Skipping build of: ../libs/date_time/test/date_time_serialization <build>no in common properties Skipping build of: ../libs/disjoint_sets/disjoint_sets <build>no in common properties Skipping build of: ../libs/dynamic_bitset/dynamic_bitset <build>no in common properties Skipping build of: ../libs/exception/test/is_output_streamable_test <build>no in common properties Any idea what's up with this? The Sandia-leopard-x86 results didn't seem to suffer from this problem last night. Thanks. -- Noel
K. Noel Belcourt wrote:
Hi,
The Sandia-darwin-intel-11.0 results are failing because essentially every Boost product is not being built (actually being skipped). This message is present for almost every Boost library.
Skipping build of: ../libs/date_time/test/date_time_serialization <build>no in common properties Skipping build of: ../libs/disjoint_sets/disjoint_sets <build>no in common properties Skipping build of: ../libs/dynamic_bitset/dynamic_bitset <build>no in common properties Skipping build of: ../libs/exception/test/is_output_streamable_test <build>no in common properties
Any idea what's up with this? The Sandia-leopard-x86 results didn't seem to suffer from this problem last night.
Can you manually run any of the skipped test, adding --debug-building to bjam command line? - Volodya
On Dec 14, 2008, at 1:16 PM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
Hi,
The Sandia-darwin-intel-11.0 results are failing because essentially every Boost product is not being built (actually being skipped). This message is present for almost every Boost library.
Skipping build of: ../libs/date_time/test/date_time_serialization <build>no in common properties Skipping build of: ../libs/disjoint_sets/disjoint_sets <build>no in common properties Skipping build of: ../libs/dynamic_bitset/dynamic_bitset <build>no in common properties Skipping build of: ../libs/exception/test/is_output_streamable_test <build>no in common properties
Any idea what's up with this? The Sandia-leopard-x86 results didn't seem to suffer from this problem last night.
Can you manually run any of the skipped test, adding --debug-building to bjam command line?
Adding this flag generates significantly more detailed output, but it appears that the same libraries are still being skipped. -- Noel
K. Noel Belcourt wrote:
On Dec 14, 2008, at 1:16 PM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
Hi,
The Sandia-darwin-intel-11.0 results are failing because essentially every Boost product is not being built (actually being skipped). This message is present for almost every Boost library.
Skipping build of: ../libs/date_time/test/date_time_serialization <build>no in common properties Skipping build of: ../libs/disjoint_sets/disjoint_sets <build>no in common properties Skipping build of: ../libs/dynamic_bitset/dynamic_bitset <build>no in common properties Skipping build of: ../libs/exception/test/is_output_streamable_test <build>no in common properties
Any idea what's up with this? The Sandia-leopard-x86 results didn't seem to suffer from this problem last night.
Can you manually run any of the skipped test, adding --debug-building to bjam command line?
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 option is not supposed to change the behaviour. And for avoidable of doubt -- it's best to get the output for a single test. - Volodya
On Dec 14, 2008, at 3:02 PM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
On Dec 14, 2008, at 1:16 PM, Vladimir Prus wrote:
K. Noel Belcourt wrote:
Hi,
The Sandia-darwin-intel-11.0 results are failing because essentially every Boost product is not being built (actually being skipped). This message is present for almost every Boost library.
Skipping build of: ../libs/date_time/test/date_time_serialization <build>no in common properties Skipping build of: ../libs/disjoint_sets/disjoint_sets <build>no in common properties Skipping build of: ../libs/dynamic_bitset/dynamic_bitset <build>no in common properties Skipping build of: ../libs/exception/test/ is_output_streamable_test <build>no in common properties
Any idea what's up with this? The Sandia-leopard-x86 results didn't seem to suffer from this problem last night.
Can you manually run any of the skipped test, adding --debug- building to bjam command line?
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 option 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. -- Noel
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 option 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? - Volodya
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 option 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. -shared-intel Causes Intel-provided libraries to be linked in dynami- cally. Architectures: IA-32, Intel(R) 64, IA-64 architectures Default: OFF Intel libraries are linked in stati- cally, with the exception of libguide on Linux* and Mac OS* X systems, where it is linked in dynamically. Description: This option causes Intel-provided libraries to be linked in dynamically. It is the opposite of -static-intel. NOTE: On Mac OS X systems, when you set "Intel Runtime Libraries" to "Dynamic", you must also set the 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/ libs/assign/test/multi_index_container.test/intel-darwin-11.0/debug/ multi_index_container Reason: Incompatible library version: multi_index_container requires version 1.0.0 or later, but libintlc.dylib provides version 0.0.0 Even though my environment has DYLD_LIBRARY_PATH set correctly. DYLD_LIBRARY_PATH=/opt/intel/Compiler/11.0/056/lib 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 -- Noel
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 option 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.
-shared-intel
Causes Intel-provided libraries to be linked in dynami- cally.
Architectures: IA-32, Intel(R) 64, IA-64 architectures
Default:
OFF Intel libraries are linked in stati- cally, with the exception of libguide on Linux* and Mac OS* X systems, where it is linked in dynamically.
Description:
This option causes Intel-provided libraries to be linked in dynamically. It is the opposite of -static-intel.
NOTE: On Mac OS X systems, when you set "Intel Runtime Libraries" to "Dynamic", you must also set the 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/ libs/assign/test/multi_index_container.test/intel-darwin-11.0/debug/ multi_index_container Reason: Incompatible library version: multi_index_container requires version 1.0.0 or later, but libintlc.dylib provides version 0.0.0
Even though my environment has DYLD_LIBRARY_PATH set correctly.
DYLD_LIBRARY_PATH=/opt/intel/Compiler/11.0/056/lib
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-command [ os.shared-library-path-variable ] : $(dll-paths) ] ; is commented out, does this improve things for runtime-link=shared? - Volodya
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 option 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.
-shared-intel
Causes Intel-provided libraries to be linked in dynami- cally.
Architectures: IA-32, Intel(R) 64, IA-64 architectures
Default:
OFF Intel libraries are linked in stati- cally, with the exception of libguide on Linux* and Mac OS* X systems, where it is linked in dynamically.
Description:
This option causes Intel-provided libraries to be linked in dynamically. It is the opposite of -static-intel.
NOTE: On Mac OS X systems, when you set "Intel Runtime Libraries" to "Dynamic", you must also set the 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/ libs/assign/test/multi_index_container.test/intel-darwin-11.0/debug/ multi_index_container Reason: Incompatible library version: multi_index_container requires version 1.0.0 or later, but libintlc.dylib provides version 0.0.0
Even though my environment has DYLD_LIBRARY_PATH set correctly.
DYLD_LIBRARY_PATH=/opt/intel/Compiler/11.0/056/lib
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- command [ 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! -- Noel
on Mon Dec 15 2008, "K. Noel Belcourt" <kbelco-AT-sandia.gov> wrote:
If you edit testing.jam, run-path-setup function so that this block:
PATH_SETUP on $(target) = [ common.prepend-path-variable- command [ 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!
Still, shouldn't this work with runtime-link=static? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Dec 15, 2008, at 10:45 AM, David Abrahams wrote:
on Mon Dec 15 2008, "K. Noel Belcourt" <kbelco-AT-sandia.gov> wrote:
If you edit testing.jam, run-path-setup function so that this block:
PATH_SETUP on $(target) = [ common.prepend-path-variable- command [ 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!
Still, shouldn't this work with runtime-link=static?
Yes, I believe it should. -- Noel
David Abrahams wrote:
on Mon Dec 15 2008, "K. Noel Belcourt" <kbelco-AT-sandia.gov> wrote:
If you edit testing.jam, run-path-setup function so that this block:
PATH_SETUP on $(target) = [ common.prepend-path-variable- command [ 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!
Still, shouldn't this work with runtime-link=static?
No. It's not possible to use static runtime with shared libraries on Linux, last time I've checked. - Volodya
participants (3)
-
David Abrahams -
K. Noel Belcourt -
Vladimir Prus