Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy.
Well, no, we should fix whatever is causing the regressions. But as far as I can tell from the link you posted, only Intel 8.0 is having a problem. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy.
Well, no, we should fix whatever is causing the regressions.
What regressions are you referring to? Everything besides "data_members" has been failing in 1.31 as well. I was talking about green/yellow failures -- about 1/3 of the tests fail; is the library still usable in this state?
But as far as I can tell from the link you posted, only Intel 8.0 is having a problem.
And, judging from the Martin's 1.31 results XML, it's not a regression either. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy.
Well, no, we should fix whatever is causing the regressions.
What regressions are you referring to? Everything besides "data_members" has been failing in 1.31 as well. I was talking about green/yellow failures -- about 1/3 of the tests fail; is the library still usable in this state?
Oh, I understand. The problems with gcc-2 only occur when C++ exceptions are thrown and the framework catches them, which happens quite often in those tests. So technically gcc-2 is usable if you're careful. As for Intel, it certainly used to work at some point, and I'm pretty sure LBL is using it successfully. My guess is that it's a linking problem that we can correct.
But as far as I can tell from the link you posted, only Intel 8.0 is having a problem.
And, judging from the Martin's 1.31 results XML, it's not a regression either.
I understand. If we can't fix the supposed linking problem I think we should mark it unusable. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
As for Intel, it certainly used to work at some point, and I'm pretty sure LBL is using it successfully.
I haven't used the Intel compiler for a while. Last time I tried everything compiled and linked but some tests failed at runtime (for unknown reasons).
My guess is that it's a linking problem that we can correct.
Intel 7.1 doesn't have a linking problem I know about, but 8.0 requires special attention, e.g.: /opt/intel_cc_80/bin/icc -shared -o libirc.so /opt/intel_cc_80/lib/libirc.a I put libirc.so somewhere on LD_LIBRARY_PATH. I also had to define LD_PRELOAD, e.g.: LD_PRELOAD="<your_path_here>/libirc.so:/opt/intel_cc_80/lib/libunwind.so.5" export LD_PRELOAD Some of this may not be necessary if the -cxxlib option is used, but I never tried it out. This is all I know. Hope it helps. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy.
Well, no, we should fix whatever is causing the regressions.
What regressions are you referring to? Everything besides "data_members" has been failing in 1.31 as well. I was talking about green/yellow failures -- about 1/3 of the tests fail; is the library still usable in this state?
Oh, I understand.
The problems with gcc-2 only occur when C++ exceptions are thrown and the framework catches them, which happens quite often in those tests. So technically gcc-2 is usable if you're careful.
OK. Does that imply that somebody is going to look into fixing "data_members" regression with gcc-2.95.3-linux* (http://tinyurl.com/5p9jz)?
As for Intel, it certainly used to work at some point, and I'm pretty sure LBL is using it successfully. My guess is that it's a linking problem that we can correct.
But as far as I can tell from the link you posted, only Intel 8.0 is having a problem.
And, judging from the Martin's 1.31 results XML, it's not a regression either.
I understand. If we can't fix the supposed linking problem I think we should mark it unusable.
OK. Martin, could you please upload your latest regression's bjam log to our FTP? -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy.
Well, no, we should fix whatever is causing the regressions.
What regressions are you referring to? Everything besides "data_members" has been failing in 1.31 as well. I was talking about green/yellow failures -- about 1/3 of the tests fail; is the library still usable in this state?
Oh, I understand.
The problems with gcc-2 only occur when C++ exceptions are thrown and the framework catches them, which happens quite often in those tests. So technically gcc-2 is usable if you're careful.
OK. Does that imply that somebody is going to look into fixing "data_members" regression with gcc-2.95.3-linux* (http://tinyurl.com/5p9jz)?
It's inconcievable to me that it could have passed in 1.31.0, since this is part of the test (which hasn't changed):
try: x.x = 77 ... except AttributeError: pass ... else: print 'no error'
So I don't think a fix is possible or practical. On second thought, let me try something; maybe something simple can be done about the majority of these failures. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
OK. Does that imply that somebody is going to look into fixing "data_members" regression with gcc-2.95.3-linux* (http://tinyurl.com/5p9jz)?
It's inconcievable to me that it could have passed in 1.31.0, since this is part of the test (which hasn't changed):
try: x.x = 77 ... except AttributeError: pass ... else: print 'no error'
So I don't think a fix is possible or practical.
On second thought, let me try something; maybe something simple can be done about the majority of these failures.
I'm afraid it didn't pan out. I still can't understand how this could be a regression. I don't think it's fixable or could have ever worked in the first place. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
David Abrahams <dave@boost-consulting.com> writes:
OK. Does that imply that somebody is going to look into fixing "data_members" regression with gcc-2.95.3-linux* (http://tinyurl.com/5p9jz)?
It's inconcievable to me that it could have passed in 1.31.0, since this is part of the test (which hasn't changed):
try: x.x = 77 ... except AttributeError: pass ... else: print 'no error'
So I don't think a fix is possible or practical.
On second thought, let me try something; maybe something simple can be done about the majority of these failures.
I'm afraid it didn't pan out. I still can't understand how this could be a regression. I don't think it's fixable or could have ever worked in the first place.
Well, all I can say that it's marked as "success" in Martin's 1.31 results: <test-result library="python" test-name="data_members" toolset="intel-7.1-stdlib-native-linux" result="success"/> <test-result library="python" test-name="data_members" toolset="gcc-3.4.0-linux" result="success"/> <test-result library="python" test-name="data_members" toolset="intel-7.1-linux" result="fail"/> <test-result library="python" test-name="data_members" toolset="gcc-3.1-linux" result="success"/> <test-result library="python" test-name="data_members" toolset="gcc-3.2.2-linux" result="success"/> <test-result library="python" test-name="data_members" toolset="gcc-2.95.3-stlport-4.5.3-linux" result="success"/> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <test-result library="python" test-name="data_members" toolset="gcc-3.3-linux" result="success"/> <test-result library="python" test-name="data_members" toolset="gcc-3.2.3-linux" result="success"/> <test-result library="python" test-name="data_members" toolset="gcc-3.3.1-linux" result="success"/> <test-result library="python" test-name="data_members" toolset="gcc-2.95.3-linux" result="success"/> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <test-result library="python" test-name="data_members" toolset="gcc-3.3.2-linux" result="success"/> But if you are positive that there is no way it could have passed, I'm going to mark it up as expected. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
But if you are positive that there is no way it could have passed, I'm going to mark it up as expected.
Well, with compiler bugs I suppose that anything's possible. Let's just say that the test code used to do all the same things to stimulate the bug, and the bug was a problem for that version of BPL, too. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Aleksey Gurtovoy writes:
But if you are positive that there is no way it could have passed, I'm going to mark it up as expected.
OK, I marked up all Python tests failing with gcc-2.95.3* as expected with a placeholder note extracted from your mail -- http://tinyurl.com/47d5f. Please feel free to adjust the wording as you deem appropriate. -- Aleksey Gurtovoy MetaCommunications Engineering
Martin Wille writes:
Martin, could you please upload your latest regression's bjam log to our FTP?
Done.
Uhm, sorry, I wasn't clear enough. I meant the bjam log for all compilers, but if you have them separately, then the one for "intel-8.0-linux" toolset. Thanks in advance! -- Aleksey Gurtovoy MetaCommunications Engineering
Martin Wille writes:
Aleksey Gurtovoy wrote:
Uhm, sorry, I wasn't clear enough. I meant the bjam log for all compilers, but if you have them separately, then the one for "intel-8.0-linux" toolset.
Sorry, I didn't read the thread completely.
intel-8.0 uploaded.
Thank you! Hmm, the log shows that all Boost.Python files fail to compile with the same diagnostics: intel-linux-C++-action ../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/numeric.o icc: error: could not find directory in which the set of libstdc++ include files resides ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ . /opt/intel_cc_80/bin/iccvars.sh icc -c -w1 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -cxxlib-gcc -KPIC -I"../bin/boost/libs/python/build" -I"/usr /include" -I"/usr/include/python2.2" -I"/boost/head-regression/boost" -o "../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/numeric.o" "/boost/head-regression/boost/libs/python/build/../src/numeric.cpp" ...failed intel-linux-C++-action ../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/numeric.o... intel-linux-C++-action ../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/list.o icc: error: could not find directory in which the set of libstdc++ include files resides ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ . /opt/intel_cc_80/bin/iccvars.sh icc -c -w1 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -cxxlib-gcc -KPIC -I"../bin/boost/libs/python/build" -I"/usr /include" -I"/usr/include/python2.2" -I"/boost/head-regression/boost" -o "../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/list.o" "/boost/head-regression/boost/libs/python/build/../src/list.cpp" etc. Any ideas what's up here? -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Thank you! Hmm, the log shows that all Boost.Python files fail to compile with the same diagnostics:
intel-linux-C++-action ../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/numeric.o icc: error: could not find directory in which the set of libstdc++ include files resides [...]
Any ideas what's up here?
Yes. That's one of the annoying problems with the intel compilers on my system. It doesn't parse the output of --print-search-dirs correctly. Thus it can't find the libstdc++ library files. I had a workaround for that, which was lost when I upgraded the compiler :( I'll reinvent that workaround. Regards, m
Martin Wille writes:
Aleksey Gurtovoy wrote:
Thank you! Hmm, the log shows that all Boost.Python files fail to compile with the same diagnostics:
intel-linux-C++-action ../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/numeric.o icc: error: could not find directory in which the set of libstdc++ include files resides [...]
Any ideas what's up here?
Yes. That's one of the annoying problems with the intel compilers on my system. It doesn't parse the output of --print-search-dirs correctly. Thus it can't find the libstdc++ library files.
I had a workaround for that, which was lost when I upgraded the compiler :( I'll reinvent that workaround.
Martin, While the missing cells fix is still in works, could you please upload the new Intel-8.0 log to us again? TIA, -- Aleksey Gurtovoy MetaCommunications Engineering
Martin Wille writes:
Aleksey Gurtovoy wrote:
Martin, While the missing cells fix is still in works, could you please upload the new Intel-8.0 log to us again?
Done.
Thank you! The first thing I see is this: intel-linux-C++-action ../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/numeric.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/limits(280): error: identifier "__CHAR_BIT__" is undefined static const int digits = __glibcpp_digits (char); ^ /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/limits(330): error: identifier "__CHAR_BIT__" is undefined static const int digits = __glibcpp_digits (signed char); ^ /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/limits(326): error: identifier "__SCHAR_MAX__" is undefined { return -__SCHAR_MAX__ - 1; } ^ ... Any clues of what's up here? -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
The first thing I see is this:
intel-linux-C++-action ../bin/boost/libs/python/build/libboost_python.so/intel-8.0-linux/debug/shared-linkable-true/stdlib-gcc/numeric.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/limits(280): error: identifier "__CHAR_BIT__" is undefined static const int digits = __glibcpp_digits (char); ^
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/limits(330): error: identifier "__CHAR_BIT__" is undefined static const int digits = __glibcpp_digits (signed char); ^
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3/limits(326): error: identifier "__SCHAR_MAX__" is undefined { return -__SCHAR_MAX__ - 1; } ^ ...
Any clues of what's up here?
Hmm, no. The __glibcpp_digits macro gets defined unconditionally in g++-v3/limits, lines 140/141. It gets undefined in line 1050 of the same file. The first error is in line 280. The error can be reproduced here with a source file that consists only of #include <limits> I'll try to look into that again tomorrow. Regards, m
participants (4)
-
Aleksey Gurtovoy -
David Abrahams -
Martin Wille -
Ralf W. Grosse-Kunstleve