Thread/intel-8.0-linux regressions

Does anybody have any ideas what's up with this (http://tinyurl.com/6vecl): Linker output []: Chmod1 ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/threading-multi/test_tss Run output []: EXIT STATUS: 139 ? All thread tests are failing in the similar manner. This is really unpleasant given that the library worked on Intel 8.0/Linux in 1.31. -- Aleksey Gurtovoy MetaCommunications Engineering

Linker output []: Chmod1 ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/threading-multi/test_tss
Run output []:
EXIT STATUS: 139
?
All thread tests are failing in the similar manner. This is really unpleasant given that the library worked on Intel 8.0/Linux in 1.31.
There are two issues here: 1) Intel 8.1 currently crashes on all tests that use the unit test suite, Intel tell me this will be fixed soon. 2) Intel 8.0 and 8.1: Martin Wille's tests are run on a Linux version that unsupported by Intel, as a result all tests that use <threading>multi fail during program startup, see for example http://tinyurl.com/4kvja. I don't see a solution to this unless we can either get someone else to run Intel on Linux, or else persuade Martin to use a different Linux vendor :-( John.

John Maddock wrote:
Linker output []: Chmod1 ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/threading-multi/test_tss
Run output []:
EXIT STATUS: 139
?
All thread tests are failing in the similar manner. This is really unpleasant given that the library worked on Intel 8.0/Linux in 1.31.
There are two issues here:
1) Intel 8.1 currently crashes on all tests that use the unit test suite, Intel tell me this will be fixed soon. 2) Intel 8.0 and 8.1: Martin Wille's tests are run on a Linux version that unsupported by Intel, as a result all tests that use <threading>multi fail during program startup, see for example http://tinyurl.com/4kvja.
Intel 8.0 apparently wants glibc 2.2 or earlier. I'm using glibc 2.3 here. (glibc 2.3.2 was released in 2003-03, so this is *not* bleeding edge software) I don't see a solution to this unless we can
either get someone else to run Intel on Linux, or else persuade Martin to use a different Linux vendor :-(
Not an option. However, I'm still working on getting a permission to run the tests on a different machine. I upgraded to 8.0.066_pe070.1 in the hope that this fixes the issues. I'm not very optimistic, though. Regards, m

Intel 8.0 apparently wants glibc 2.2 or earlier. I'm using glibc 2.3 here. (glibc 2.3.2 was released in 2003-03, so this is *not* bleeding edge software)
I know :-(
I don't see a solution to this unless we can
either get someone else to run Intel on Linux, or else persuade Martin to use a different Linux vendor :-(
Not an option. However, I'm still working on getting a permission to run the tests on a different machine.
I upgraded to 8.0.066_pe070.1 in the hope that this fixes the issues. I'm not very optimistic, though.
I wonder, what happens if you use the -cxxlib-gcc option, would that be enough to get the tests to run? It's not an ideal solution, but it's better than the status quo. Thanks for trying anyway, John.

Martin Wille wrote:
I upgraded to 8.0.066_pe070.1 in the hope that this fixes the issues. I'm not very optimistic, though.
The upgrade fixed *some* problems. E.g. the config tests don't crash anymore. Now, there seem to be problems with strtol() (e.g. http://tinyurl.com/6f8hu ) Regards, m

The upgrade fixed *some* problems. E.g. the config tests don't crash anymore. Now, there seem to be problems with strtol() (e.g. http://tinyurl.com/6f8hu )
I notice that test uses <runtime-link>static is that the cause of the failure? I've no idea why that test would be built with that option anyway, John.
participants (3)
-
Aleksey Gurtovoy
-
John Maddock
-
Martin Wille