Re: [boost] Regressions in your Boost libraries as of 2005-07-06
Douglas Gregor <dgregor@cs.indiana.edu> writes:
You are receiving this report because one or more of the libraries you maintain has regression test failures that are not accounted for. A full version of the report is sent to the Boost developer's mailing list.
Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues....
There are failures in these libraries you maintain: python (11)
|python| extract: gcc-3.4.4-linux gcc-4.0.0-linux list: gcc-3.4.4-linux gcc-4.0.0-linux pickle1: gcc-3.4.4-linux gcc-4.0.0-linux pickle2: gcc-3.4.4-linux pickle3: gcc-3.4.4-linux gcc-4.0.0-linux pickle4: gcc-3.4.4-linux gcc-4.0.0-linux
What happened here? I haven't changed anything in Boost.Python, and the error reports on the site above are inscrutable. Are you setting PYTHON_ROOT in these toolsets, by any chance? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jul 6, 2005, at 12:23 PM, David Abrahams wrote:
Douglas Gregor <dgregor@cs.indiana.edu> writes:
You are receiving this report because one or more of the libraries you maintain has regression test failures that are not accounted for. A full version of the report is sent to the Boost developer's mailing list.
Detailed report:
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ issues.html
There are failures in these libraries you maintain: python (11)
|python| extract: gcc-3.4.4-linux gcc-4.0.0-linux list: gcc-3.4.4-linux gcc-4.0.0-linux pickle1: gcc-3.4.4-linux gcc-4.0.0-linux pickle2: gcc-3.4.4-linux pickle3: gcc-3.4.4-linux gcc-4.0.0-linux pickle4: gcc-3.4.4-linux gcc-4.0.0-linux
What happened here? I haven't changed anything in Boost.Python, and the error reports on the site above are inscrutable. Are you setting PYTHON_ROOT in these toolsets, by any chance?
Those are the Martin Wille tests that are failing; the OSL tests are all passing. Martin, to run the Python tests you'll probably need to build different versions of Python for the different compilers. Something in the newer GCCs causes very bad behavior when Python is built with a different compiler than Boost.Python. Doug
Doug Gregor <dgregor@cs.indiana.edu> writes:
On Jul 6, 2005, at 12:23 PM, David Abrahams wrote:
Douglas Gregor <dgregor@cs.indiana.edu> writes:
You are receiving this report because one or more of the libraries you maintain has regression test failures that are not accounted for. A full version of the report is sent to the Boost developer's mailing list.
Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ issues.html
There are failures in these libraries you maintain: python (11)
|python| extract: gcc-3.4.4-linux gcc-4.0.0-linux list: gcc-3.4.4-linux gcc-4.0.0-linux pickle1: gcc-3.4.4-linux gcc-4.0.0-linux pickle2: gcc-3.4.4-linux pickle3: gcc-3.4.4-linux gcc-4.0.0-linux pickle4: gcc-3.4.4-linux gcc-4.0.0-linux
What happened here? I haven't changed anything in Boost.Python, and the error reports on the site above are inscrutable. Are you setting PYTHON_ROOT in these toolsets, by any chance?
Those are the Martin Wille tests that are failing; the OSL tests are all passing. Martin, to run the Python tests you'll probably need to build different versions of Python for the different compilers.
Doug, I know you've drawn that conclusion, but it really surprises me. Generally speaking, I have been able to use any version of Python with any compiler, provided Python was compiled with something having a compatible 'C' ABI.
Something in the newer GCCs causes very bad behavior when Python is built with a different compiler than Boost.Python.
I'm going to check this out on the Python list; it sounds fishy. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jul 6, 2005, at 4:53 PM, David Abrahams wrote:
Doug Gregor <dgregor@cs.indiana.edu> writes:
Those are the Martin Wille tests that are failing; the OSL tests are all passing. Martin, to run the Python tests you'll probably need to build different versions of Python for the different compilers.
Doug, I know you've drawn that conclusion, but it really surprises me. Generally speaking, I have been able to use any version of Python with any compiler, provided Python was compiled with something having a compatible 'C' ABI.
I dunno what else to say. You're free to play around with things on our Linux machine (eddie); we have various flavors of GCC 3.3 and 3.4 available, with Pythons compiled with those plus the system GCC 3.3.5. GCC 2.95.3 (with or without STLport) works fine with the system Python (compiled with the system's GCC 3.3.5), but Boost.Python tests fail to run properly unless Python is recompiled with the same GCC 3.3.6 or 3.4.4. Doug
Doug Gregor <dgregor@cs.indiana.edu> writes:
On Jul 6, 2005, at 4:53 PM, David Abrahams wrote:
Doug Gregor <dgregor@cs.indiana.edu> writes:
Those are the Martin Wille tests that are failing; the OSL tests are all passing. Martin, to run the Python tests you'll probably need to build different versions of Python for the different compilers.
Doug, I know you've drawn that conclusion, but it really surprises me. Generally speaking, I have been able to use any version of Python with any compiler, provided Python was compiled with something having a compatible 'C' ABI.
I dunno what else to say. You're free to play around with things on our Linux machine (eddie); we have various flavors of GCC 3.3 and 3.4 available, with Pythons compiled with those plus the system GCC 3.3.5. GCC 2.95.3 (with or without STLport) works fine with the system Python (compiled with the system's GCC 3.3.5), but Boost.Python tests fail to run properly unless Python is recompiled with the same GCC 3.3.6 or 3.4.4.
Well, I've done this numerous times on numerous machines. I wonder what's up with eddie? Ralf, does this sound normal to you? -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
Doug, I know you've drawn that conclusion, but it really surprises me. Generally speaking, I have been able to use any version of Python with any compiler, provided Python was compiled with something having a compatible 'C' ABI.
I dunno what else to say. You're free to play around with things on our Linux machine (eddie); we have various flavors of GCC 3.3 and 3.4 available, with Pythons compiled with those plus the system GCC 3.3.5. GCC 2.95.3 (with or without STLport) works fine with the system Python (compiled with the system's GCC 3.3.5), but Boost.Python tests fail to run properly unless Python is recompiled with the same GCC 3.3.6 or 3.4.4.
Well, I've done this numerous times on numerous machines. I wonder what's up with eddie? Ralf, does this sound normal to you?
(Newer?) Python executables are linked with "g++" (instead of "gcc"), which brings in libstdc++.so. We had weird crashes when using a Python compiled on a machine with libstdc++.so.5 (Redhat 8.0) for building Boost.Python extensions on another machine which had libstdc++.so.6 (Gentoo 1.6.8 and Fedora core 3, I believe). To check for libstdc++ incompatibilities, run ldd <full-path-to>/python and, e.g., ldd <full-path-to>/minimal_ext.so Look for lines like libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000002a95689000) HTH, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Jul 6, 2005, at 9:04 PM, Ralf W. Grosse-Kunstleve wrote:
(Newer?) Python executables are linked with "g++" (instead of "gcc"), which brings in libstdc++.so. We had weird crashes when using a Python compiled on a machine with libstdc++.so.5 (Redhat 8.0) for building Boost.Python extensions on another machine which had libstdc++.so.6 (Gentoo 1.6.8 and Fedora core 3, I believe).
To check for libstdc++ incompatibilities, run
ldd <full-path-to>/python
On eddie (one of the trouble systems), this gives: libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 (0xb7dd8000) for the Python installed on the system.
and, e.g.,
ldd <full-path-to>/minimal_ext.so
... and this gives (for eddie's GCC 4.0.0): libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.0.0-alpha20050213/libstdc++.so.6 (0xb7f0d000) It looks like that's the problem, then. We have two libstdc++ versions around, hence the need to build Boost.Python with the same compiler version as Python. Bummer. I wonder... does Python even use C++? Should they just be linking with gcc? Doug
--- Douglas Gregor <doug.gregor@gmail.com> wrote:
It looks like that's the problem, then. We have two libstdc++ versions around, hence the need to build Boost.Python with the same compiler version as Python. Bummer.
I wonder... does Python even use C++?
Not to my knowledge. I guess they just wanted to do a favor to people using C++ extensions. Or maybe it is an oversight? Either the comment in configure.in is out of date or the script has a bug (Python 2.4.1 sources): # LINKCC is the command that links the python executable -- default is $(CC). # If CXX is set, and if it is needed to link a main function that was # compiled with CXX, LINKCC is CXX instead. Always using CXX is undesirable: # python might then depend on the C++ runtime # This is altered for AIX in order to build the export list before # linking.
Should they just be linking with gcc?
Try this in the Python source code directory: ./configure LINKCC=gcc It works for Python 2.4.1 under Fedora Core 3 (x86_64). Cheers, Ralf ____________________________________________________ Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- Douglas Gregor <doug.gregor@gmail.com> wrote:
It looks like that's the problem, then. We have two libstdc++ versions around, hence the need to build Boost.Python with the same compiler version as Python. Bummer.
I wonder... does Python even use C++?
Not to my knowledge. I guess they just wanted to do a favor to people using C++ extensions. Or maybe it is an oversight? Either the comment in configure.in is out of date or the script has a bug (Python 2.4.1 sources):
# LINKCC is the command that links the python executable -- default is $(CC). # If CXX is set, and if it is needed to link a main function that was # compiled with CXX, LINKCC is CXX instead. Always using CXX is undesirable: # python might then depend on the C++ runtime # This is altered for AIX in order to build the export list before # linking.
Should they just be linking with gcc?
Try this in the Python source code directory:
./configure LINKCC=gcc
It works for Python 2.4.1 under Fedora Core 3 (x86_64).
The advice I got on python-dev was: Configure with --without-cxx -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
The advice I got on python-dev was:
Configure with --without-cxx
I tried that when we had the problem with icc. It didn't help. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille <mw8329@yahoo.com.au> writes:
David Abrahams wrote:
The advice I got on python-dev was:
Configure with --without-cxx
I tried that when we had the problem with icc. It didn't help.
But ICC has very particular issues here; the details may be different for g++. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jul 7, 2005, at 9:37 AM, David Abrahams wrote:
The advice I got on python-dev was:
Configure with --without-cxx
FYI, I just built a Python this way using Eddie's system compiler, and all of the Python tests (with GCC 3.3.6 and 3.4.4) seem to run fine using that Python. I'm switching Eddie over to this mode for its nightly tests and we'll see what happens. Doug
Doug Gregor wrote:
On Jul 6, 2005, at 4:53 PM, David Abrahams wrote:
Doug Gregor <dgregor@cs.indiana.edu> writes:
Those are the Martin Wille tests that are failing; the OSL tests are all passing. Martin, to run the Python tests you'll probably need to build different versions of Python for the different compilers.
Doug, I know you've drawn that conclusion, but it really surprises me. Generally speaking, I have been able to use any version of Python with any compiler, provided Python was compiled with something having a compatible 'C' ABI.
I dunno what else to say. You're free to play around with things on our Linux machine (eddie); we have various flavors of GCC 3.3 and 3.4 available, with Pythons compiled with those plus the system GCC 3.3.5. GCC 2.95.3 (with or without STLport) works fine with the system Python (compiled with the system's GCC 3.3.5), but Boost.Python tests fail to run properly unless Python is recompiled with the same GCC 3.3.6 or 3.4.4.
GCC 3.3.5 is the system compiler here, too (no surprise, since we're both using Gentoo.) The GCC 3.3.6 tests seem to run fine. 3.4.4 and 4.0.0 produce segmentation faults for a couple of the Boost.Python tests. One of the failing tests is exception_translator. This smells like a problem similar to what we had with Intel. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille <mw8329@yahoo.com.au> writes:
GCC 3.3.5 is the system compiler here, too (no surprise, since we're both using Gentoo.) The GCC 3.3.6 tests seem to run fine. 3.4.4 and 4.0.0 produce segmentation faults for a couple of the Boost.Python tests.
One of the failing tests is exception_translator. This smells like a problem similar to what we had with Intel.
Could be, yes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
David Abrahams -
Doug Gregor -
Douglas Gregor -
Martin Wille -
Ralf W. Grosse-Kunstleve