Boost.Python in SUSE 9.0 or SUSE 9.1?
Hi all, Has anyone successfully used Boost.Python in SUSE 9.0 or SUSE 9.1? In 9.0 I had to build and install boost 1.31 from source, but 9.1 comes with a boost 1.31 package. Either way, merely #including <boost/python.hpp> causes an internal compiler error in a variety of places. Note: SUSE 9.0 uses gcc 3.3.1 (+ SUSE-specific patches?) and SUSE 9.1 uses gcc 3.3.3 (+ patches again?). If I build gcc 3.4.0 from source, Boost.Python compiles, but does not link do to incompatibilities in libstdc++. I'm going to try Boost.Python from CVS before anything else, but I thought I'd ask if anyone else has had success or failure in this area. Thanks, Chad
--- Chad Austin <caustin@gmail.com> wrote:
Has anyone successfully used Boost.Python in SUSE 9.0 or SUSE 9.1? In 9.0 I had to build and install boost 1.31 from source, but 9.1 comes with a boost 1.31 package. Either way, merely #including <boost/python.hpp> causes an internal compiler error in a variety of places. Note: SUSE 9.0 uses gcc 3.3.1 (+ SUSE-specific patches?) and SUSE 9.1 uses gcc 3.3.3 (+ patches again?).
I've used gcc 3.3.1 under Mandrake 9.2 and SunOS 5.9 without problems, but didn't have the opportunity to try SUSE.
If I build gcc 3.4.0 from source, Boost.Python compiles, but does not link do to incompatibilities in libstdc++.>
Does the link command fail, or is it a run-time failure (i.e. dlopen fails)? If it is the latter you might have to update the LD_LIBRARY_PATH. This is what I am using to activate gcc 3.4 in a new shell: set path=(/usr/local_cci/gcc-3.4.0/bin $path) if ( $?LD_LIBRARY_PATH ) then setenv LD_LIBRARY_PATH "/usr/local_cci/gcc-3.4.0/lib:${LD_LIBRARY_PATH}" else setenv LD_LIBRARY_PATH "/usr/local_cci/gcc-3.4.0/lib" endif
I'm going to try Boost.Python from CVS before anything else, but I thought I'd ask if anyone else has had success or failure in this area.
The Boost 1.31 release has a subtle issue when compiling with gcc 3.4: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14528 If you run into this use Boost CVS. As of yesterday it was in fantastic shape. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
Hi Ralf, On Thu, 24 Jun 2004 07:42:41 -0700 (PDT), Ralf W. Grosse-Kunstleve <rwgk@yahoo.com> wrote:
--- Chad Austin <caustin@gmail.com> wrote:
Has anyone successfully used Boost.Python in SUSE 9.0 or SUSE 9.1? In 9.0 I had to build and install boost 1.31 from source, but 9.1 comes with a boost 1.31 package. Either way, merely #including <boost/python.hpp> causes an internal compiler error in a variety of places. Note: SUSE 9.0 uses gcc 3.3.1 (+ SUSE-specific patches?) and SUSE 9.1 uses gcc 3.3.3 (+ patches again?).
I've used gcc 3.3.1 under Mandrake 9.2 and SunOS 5.9 without problems, but didn't have the opportunity to try SUSE.
After some investigation, it appears SUSE applies some custom patches to their gcc builds, causing including boost/python.hpp to ICE. I've submitted a support request to SUSE for this issue. Installing a compatible gcc from source into /usr/local appears to work around the problem.
If I build gcc 3.4.0 from source, Boost.Python compiles, but does not link do to incompatibilities in libstdc++.>
Does the link command fail, or is it a run-time failure (i.e. dlopen fails)? If it is the latter you might have to update the LD_LIBRARY_PATH. This is what I am using to activate gcc 3.4 in a new shell:
I believe it was an ABI change in libstdc++ or something. My boost was compiled with gcc 3.3 and my app with 3.4. I just started getting random crashes.
set path=(/usr/local_cci/gcc-3.4.0/bin $path) if ( $?LD_LIBRARY_PATH ) then setenv LD_LIBRARY_PATH "/usr/local_cci/gcc-3.4.0/lib:${LD_LIBRARY_PATH}" else setenv LD_LIBRARY_PATH "/usr/local_cci/gcc-3.4.0/lib" endif
Awesome, thanks.
I'm going to try Boost.Python from CVS before anything else, but I thought I'd ask if anyone else has had success or failure in this area.
The Boost 1.31 release has a subtle issue when compiling with gcc 3.4:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14528
If you run into this use Boost CVS. As of yesterday it was in fantastic shape.
Thanks for the heads up! I did notice that gcc 3.4 is a lot more strict about some things. It seems to discover lots of subtle errors that other compilers don't. :) Chad
On Fri, 2004-06-25 at 10:07, Chad Austin wrote:
After some investigation, it appears SUSE applies some custom patches to their gcc builds, causing including boost/python.hpp to ICE. I've submitted a support request to SUSE for this issue. Installing a compatible gcc from source into /usr/local appears to work around the problem.
A coworker has SUSE 9.0 installed on his laptop and ran into the same issue a couple of weeks ago. He is out of the country on business right now, so I'm going on memory about what we did. When he contacted Suse about the issue, they said that they would not do anything about it, since he could install a working GCC from source. He used GCC 3.3.3 from gcc.org (it was the latest in the 3.3 series at that time), rebuilt Boost and the extensions with that, and everything worked. Using the --program-suffix= and --enable-version-specific-runtime-libs to GCC's configure ensured that the new compiler didn't stomp on Suse's custom compiler. Finally, we used the -sGXX= option to bjam to point it at the new compiler.
If I build gcc 3.4.0 from source, Boost.Python compiles, but does not link do to incompatibilities in libstdc++.>
Does the link command fail, or is it a run-time failure (i.e. dlopen fails)? If it is the latter you might have to update the LD_LIBRARY_PATH. This is what I am using to activate gcc 3.4 in a new shell:
I believe it was an ABI change in libstdc++ or something. My boost was compiled with gcc 3.3 and my app with 3.4. I just started getting random crashes.
Gcc 3.4 uses libstdc++.so.6 while GCC 3.3 and 3.2 use libstdc++.so.5. They don't mix in the same program. HTH, -Jonathan
On Tue, 22 Jun 2004, Chad Austin wrote:
Hi all,
Has anyone successfully used Boost.Python in SUSE 9.0 or SUSE 9.1? In 9.0 I had to build and install boost 1.31 from source, but 9.1 comes with a boost 1.31 package. Either way, merely #including <boost/python.hpp> causes an internal compiler error in a variety of places. Note: SUSE 9.0 uses gcc 3.3.1 (+ SUSE-specific patches?) and SUSE 9.1 uses gcc 3.3.3 (+ patches again?). If I build gcc 3.4.0 from source, Boost.Python compiles, but does not link do to incompatibilities in libstdc++. I'm going to try Boost.Python from CVS before anything else, but I thought I'd ask if anyone else has had success or failure in this area.
Thanks, Chad
Hi, I've managed to successfully compile and use a small module on SuSE 9.0 with the following setup: * gcc version 3.3.1 (SuSE Linux) * boost_1_31_0 obtained from boost site and compiled from sources * python 2.3.3 also compiled from sources. * Module: #include <boost/python/suite/indexing/vector_indexing_suite.hpp> #include <boost/python/module.hpp> #include <boost/python/def.hpp> #include <boost/python/implicit.hpp> #include "rpower.h" using namespace boost::python; BOOST_PYTHON_MODULE(fftw_ext) { class_<std::vector<fftw_real> >("fftw_realVec") .def(vector_indexing_suite<std::vector<fftw_real> >()) ; def("power_spectrum", power_spectrum); } where power_spectrum is a function defined in rpower.h with the following signature: void power_spectrum(std::vector<fftw_real> &in, std::vector<fftw_real> &out); However, I've just tried to compile a test file with just one line #include <boost/python.hpp> as mentioned in your post quoted above, which also results in an internal compiler error: g++ -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -g -O0 \ -fno-inline -fPIC -DDEBUG -I/usr/local/include/python2.3 \ -I/usr/local/include/boost-1_31 -c -o test.os test.cpp <snipped warning about _POSIX_C_SOURCE being redefined> /usr/local/include/boost-1_31/boost/python/object_core.hpp:283: internal compiler error: Segmentation fault Any clues on how to proceed from here? Thanks, Chris
--- Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
However, I've just tried to compile a test file with just one line #include <boost/python.hpp> as mentioned in your post quoted above, which also results in an internal compiler error:
g++ -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -g -O0 \ -fno-inline -fPIC -DDEBUG -I/usr/local/include/python2.3 \ -I/usr/local/include/boost-1_31 -c -o test.os test.cpp
<snipped warning about _POSIX_C_SOURCE being redefined> /usr/local/include/boost-1_31/boost/python/object_core.hpp:283: internal compiler error: Segmentation fault
Any clues on how to proceed from here?
You have to strip down the code until you've isolated the construct that causes the ICE. Then try to rearrange that construct until the ICE goes away. In the early days of Boost.Python I've done this a million times, and I am sure David did it a billion times. It always takes too long, is very frustrating, and therefore requires a lot of determination. If this is not enough to scare you, copy the content of boost/python.hpp into your source file, then comment out half the includes, see if it still ICE's, if yes comment out half of the remaining, if not put back half of the ones you commented out, and so on until you've found that one include that makes a difference. Then copy that into your source code and repeat the exercise until you found the piece of code that makes the difference. Then go into a different trial-and-error loop rearranging the code. While the first step requires mainly determination, you will need some creativity here. Often my last resort was to ask David. Finally you have to communicate the fix to the developers of the effected library (e.g. it could be in boost::graph or boost::bind or, heaven forbid, in boost::mpl or ...) and convince them to adopt your fix. Easy! Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
On Fri, 25 Jun 2004, Ralf W. Grosse-Kunstleve wrote:
You have to strip down the code until you've isolated the construct that causes the ICE. Then try to rearrange that construct until the ICE goes away. In the early days of Boost.Python I've done this a million times, and I am sure David did it a billion times. It always takes too long, is very frustrating, and therefore requires a lot of determination. If this is not enough to scare you, copy the content of boost/python.hpp into your source file, then comment out half the includes, see if it still ICE's, if yes comment out half of the remaining, if not put back half of the ones you commented out, and so on until you've found that one include that makes a difference. Then copy that into your source code and repeat the exercise until you found the piece of code that makes the difference. Then go into a different trial-and-error loop rearranging the code. While the first step requires mainly determination, you will need some creativity here. Often my last resort was to ask David. Finally you have to communicate the fix to the developers of the effected library (e.g. it could be in boost::graph or boost::bind or, heaven forbid, in boost::mpl or ...) and convince them to adopt your fix.
Okay. Thanks for the encouragement, Ralf. Here's the result of my 'investigation': On the following system: gcc version 3.3.1 (SuSE Linux 9.0) boost-1.31 if I try to compile <boost/python/detail/translate_exception.hpp> (copied to test.cpp) with the following command line g++ -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -g -O0 -fno-inline -fPIC -DDEBUG -I/usr/local/include/python2.3 -I/usr/local/include/boost-1_31 -c -o test.os test.cpp the compiler segfaults with the following message: /usr/include/g++/bits/basic_string.h:728: internal compiler error: Segmentation fault The relevant line in translate_exception.hpp triggering the segfault is indicated below: template <class ExceptionType, class Translate> struct translate_exception { typedef typename add_reference< typename add_const<ExceptionType>::type >::type exception_cref; inline bool operator()( exception_handler const& handler , function0<void> const& f , typename call_traits<Translate>::param_type translate) const { try { return handler(f); } catch(exception_cref e) --------------^^^^^^^^^^^^^^^^ { translate(e); return true; } } }; FWIW, the compiler is happy with "catch(exception_cref &e)", though I do --------------------------------------------------------^ not know whether it would be okay to make that change... Chris.
Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> writes:
FWIW, the compiler is happy with "catch(exception_cref &e)", though I do --------------------------------------------------------^ not know whether it would be okay to make that change...
Sure; you can do that in your local copy. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> writes:
FWIW, the compiler is happy with "catch(exception_cref &e)", though I do --------------------------------------------------------^ not know whether it would be okay to make that change...
Sure; you can do that in your local copy.
David is telling me:
Hi David, I think he was asking if we can make that change in the main version . I think we should unless you have objections. I can run tests on all our platforms to make sure it works everywhere. Please let me know.
Yes, I have objections, at least if you don't make the patch very precise and conditional. It will break on many compilers. The add_reference invocation above it should have already added a reference and many compilers (even most GCCs?) will choke on adding a reference to a type that is already a reference.
I.e. what we need is a very specific set of #ifdef's that will apply your patch only under SUSE 9, and only if the compiler with SUSE's patches is used. Here is an alias that is sometimes helpful in pin-pointing system specific macros: alias whatdefg++ 'echo '"'"'int main(void){return 0;}'"'"' > /var/tmp/tmp$$.cpp; g++ -E -v \!* /var/tmp/tmp$$.cpp; rm -f /var/tmp/tmp$$.cpp' Please use BOOST_WORKAROUND. There are lots of examples in the boost code, e.g. boost/python/object/value_holder.hpp. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
On Tue, 29 Jun 2004, Ralf W. Grosse-Kunstleve wrote:
--- David Abrahams <dave@boost-consulting.com> wrote:
Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> writes:
FWIW, the compiler is happy with "catch(exception_cref &e)", though I do --------------------------------------------------------^ not know whether it would be okay to make that change...
Sure; you can do that in your local copy.
David is telling me:
Hi David, I think he was asking if we can make that change in the main version . I think we should unless you have objections. I can run tests on all our platforms to make sure it works everywhere. Please let me know.
Yes, I have objections, at least if you don't make the patch very precise and conditional. It will break on many compilers. The add_reference invocation above it should have already added a reference and many compilers (even most GCCs?) will choke on adding a reference to a type that is already a reference.
I.e. what we need is a very specific set of #ifdef's that will apply your patch only under SUSE 9, and only if the compiler with SUSE's patches is used.
Hi Ralf, thanks for the pointers. Unfortunately I was unable to find a macro which would allow to decide whether the gcc-version used was patched by SuSE. So I guess, that for the time being I have to (a) install an 'official' gcc release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and gcc-3.4.0 seemes to indicate that neither minds the added reference. Should they? Chris.
Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> writes:
On Tue, 29 Jun 2004, Ralf W. Grosse-Kunstleve wrote:
--- David Abrahams <dave@boost-consulting.com> wrote:
Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> writes:
FWIW, the compiler is happy with "catch(exception_cref &e)", though I do --------------------------------------------------------^ not know whether it would be okay to make that change...
Sure; you can do that in your local copy.
David is telling me:
Hi David, I think he was asking if we can make that change in the main version . I think we should unless you have objections. I can run tests on all our platforms to make sure it works everywhere. Please let me know.
Yes, I have objections, at least if you don't make the patch very precise and conditional. It will break on many compilers. The add_reference invocation above it should have already added a reference and many compilers (even most GCCs?) will choke on adding a reference to a type that is already a reference.
I.e. what we need is a very specific set of #ifdef's that will apply your patch only under SUSE 9, and only if the compiler with SUSE's patches is used.
Hi Ralf,
thanks for the pointers. Unfortunately I was unable to find a macro which would allow to decide whether the gcc-version used was patched by SuSE. So I guess, that for the time being I have to (a) install an 'official' gcc release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and gcc-3.4.0 seemes to indicate that neither minds the added reference. Should they?
Not neccessarily. There's been a DR which says they are legal. Some earlier GCCs will barf. If you can satisfy yourself that you're not going to cause trouble, I'll be happy to accept the patch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Tue, 6 Jul 2004, David Abrahams wrote:
Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> writes:
On Tue, 29 Jun 2004, Ralf W. Grosse-Kunstleve wrote:
--- David Abrahams <dave@boost-consulting.com> wrote:
Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> writes:
FWIW, the compiler is happy with "catch(exception_cref &e)", though I do --------------------------------------------------------^ not know whether it would be okay to make that change...
Sure; you can do that in your local copy.
David is telling me:
Hi David, I think he was asking if we can make that change in the main version . I think we should unless you have objections. I can run tests on all our platforms to make sure it works everywhere. Please let me know.
Yes, I have objections, at least if you don't make the patch very precise and conditional. It will break on many compilers. The add_reference invocation above it should have already added a reference and many compilers (even most GCCs?) will choke on adding a reference to a type that is already a reference.
I.e. what we need is a very specific set of #ifdef's that will apply your patch only under SUSE 9, and only if the compiler with SUSE's patches is used.
Hi Ralf,
thanks for the pointers. Unfortunately I was unable to find a macro which would allow to decide whether the gcc-version used was patched by SuSE. So I guess, that for the time being I have to (a) install an 'official' gcc release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and gcc-3.4.0 seemes to indicate that neither minds the added reference. Should they?
Not neccessarily. There's been a DR which says they are legal. Some earlier GCCs will barf. If you can satisfy yourself that you're not going to cause trouble, I'll be happy to accept the patch.
Unfortunately I cannot as you were right in your first post forwarded by Ralf: GCC considers forming a reference to the reference type `const error&' an error. My impression that the change was okay was based on the fact that just compiling the header was possible with the additional reference. However, trying to instantiate the template, as happens when libs/python/test/exception_translator is built, results in errors as follows: <snip> ../../../libs/python/test/exception_translator.cpp:21: instantiated from here /usr/local/src/boost_1_31_0/boost/python/detail/translate_exception.hpp:38: error: forming reference to reference type `const error&' <snip> I just checked this for gcc-3.3.4 and gcc-3.4.0 (official), and gcc-3.3.1 (as shipped by SuSE 8.2) So it will have to be non-SuSE gcc's for the time being... Sorry for the noise and thanks for the help, Chris.
--- Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
I just checked this for gcc-3.3.4 and gcc-3.4.0 (official), and gcc-3.3.1 (as shipped by SuSE 8.2) So it will have to be non-SuSE gcc's for the time being...
Oh, sorry, I didn't see this before sending the other message a minute ago. Please disregard the other message. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
I just checked this for gcc-3.3.4 and gcc-3.4.0 (official), and gcc-3.3.1 (as shipped by SuSE 8.2) So it will have to be non-SuSE gcc's for the time being...
Oh, sorry, I didn't see this before sending the other message a minute ago. Please disregard the other message. Ralf
Here's what you do. You use that nasty preprocessor condition to switch in this code: template <class ExceptionType, class Translate> struct translate_exception { typedef typename remove_reference< ^^^^^^^ typename add_const<ExceptionType>::type >::type exception_non_ref; inline bool operator()( exception_handler const& handler , function0<void> const& f , typename call_traits<Translate>::param_type translate) const { try { return handler(f); } catch(exception_non_ref& e) ^^^^^^^^^^^^^^^^^^ { translate(e); return true; } } }; Then you test it thoroughly. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Wed, 7 Jul 2004, David Abrahams wrote:
Here's what you do. You use that nasty preprocessor condition to switch in this code:
template <class ExceptionType, class Translate> struct translate_exception { typedef typename remove_reference< ^^^^^^^ typename add_const<ExceptionType>::type >::type exception_non_ref;
inline bool operator()( exception_handler const& handler , function0<void> const& f , typename call_traits<Translate>::param_type translate) const { try { return handler(f); } catch(exception_non_ref& e) ^^^^^^^^^^^^^^^^^^ { translate(e); return true; } } };
Then you test it thoroughly.
Thanks for the help. I applied your workaround using BOOST_WORKAROUND as suggested by Ralf (see enclosed patch how) and successfully ran all the test in libs/python/test by invoking bjam with no arguments in that directory on the following two systems: * SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE * SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE On both systems I used boost_1_31_0 from the boost web-site. Could somebody with easy access to the official versions of gcc please test the enclosed patch, as well? Are there any other tests I could/should run? Chris.
--- Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
Thanks for the help. I applied your workaround using BOOST_WORKAROUND as suggested by Ralf (see enclosed patch how) and successfully ran all the test in libs/python/test by invoking bjam with no arguments in that directory on the following two systems:
* SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE
* SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE
On both systems I used boost_1_31_0 from the boost web-site.
Could somebody with easy access to the official versions of gcc please test the enclosed patch, as well?
Are there any other tests I could/should run?
Hi Chris, Thanks for the patch! I've applied it locally and I've tested with gcc 3.3.1 and gcc 3.3.3 under Red Hat 9.0 without finding any difficulties. I've also tested on a bunch of other platforms. Could you please do a last verification to make sure my version works for you? Please get this file: http://cci.lbl.gov/~rwgk/tmp/boost_2004_07_07_1512.tar.gz Unpack and run bjam as before. If you can confirm that it works as expected under SuSE 9.x I'll check the patch into the main version. Thanks! Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
On Wed, 7 Jul 2004, Ralf W. Grosse-Kunstleve wrote:
Hi Chris,
Thanks for the patch! I've applied it locally and I've tested with gcc 3.3.1 and gcc 3.3.3 under Red Hat 9.0 without finding any difficulties. I've also tested on a bunch of other platforms. Could you please do a last verification to make sure my version works for you? Please get this file:
http://cci.lbl.gov/~rwgk/tmp/boost_2004_07_07_1512.tar.gz
Unpack and run bjam as before. If you can confirm that it works as expected under SuSE 9.x I'll check the patch into the main version.
Hi Ralf, Thanks for runnung those tests! I got your tarball, unpacked it, and ran bjam in libs/python/test on * SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE Python 2.3.3 as shipped by SuSE and * SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE Python 2.3.3 from www.python.org as before. Results : ...failed updating 2 targets... ...skipped 1 target... ...updated 492 targets... Failures: (1) ...failed gcc-Link-action ../../../bin/boost/libs/python/test/select_arg_to_python_test.test/gcc/debug/threading-multi/select_arg_to_python_test... (2) ...failed gcc-C++-action ../../../bin/boost/libs/python/test/embedding.test/gcc/debug/threading-multi/embedding.o... (2b)...skipped <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding for lack of <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding.o... I guess these failures are not related to the patch, without which the results after a bjam clean; bjam invocation are as indicated below. I am enclosing the detailed error messages for the failures with patch, so you could have a look at them. HTH and thanks, Chris. Results for tests without patch: ...failed updating 9 targets... ...skipped 8 targets... ...updated 179 targets... Failures: ...failed gcc-C++-action ../../../bin/boost/libs/python/test/ben_scott1_ext.so/gcc/debug/shared-linkable-true/ben_scott1.o... ...skipped <@boost!libs!python!test/ben_scott1_ext.so/gcc/debug/shared-linkable-true>ben_scott1_ext.so for lack of <@boost!libs!python!test/ben_scott1_ext.so/gcc/debug/shared-linkable-true>ben_scott1.o... ...failed gcc-C++-action ../../../bin/boost/libs/python/test/slice_ext.so/gcc/debug/shared-linkable-true/slice.o... ...skipped <@boost!libs!python!test/slice_ext.so/gcc/debug/shared-linkable-true>slice_ext.so for lack of <@boost!libs!python!test/slice_ext.so/gcc/debug/shared-linkable-true>slice.o... ...failed gcc-C++-action ../../../bin/boost/libs/python/test/keywords.so/gcc/debug/shared-linkable-true/keywords.o... ...skipped <@boost!libs!python!test/keywords.so/gcc/debug/shared-linkable-true>keywords.so for lack of <@boost!libs!python!test/keywords.so/gcc/debug/shared-linkable-true>keywords.o... ...failed gcc-C++-action ../../../bin/boost/libs/python/test/exception_translator_ext.so/gcc/debug/shared-linkable-true/exception_translator.o... ...skipped <@boost!libs!python!test/exception_translator_ext.so/gcc/debug/shared-linkable-true>exception_translator_ext.so for lack of <@boost!libs!python!test/exception_translator_ext.so/gcc/debug/shared-linkable-true>exception_translator.o... ...failed gcc-C++-action ../../../bin/boost/libs/python/test/properties_ext.so/gcc/debug/shared-linkable-true/properties.o... ...skipped <@boost!libs!python!test/properties_ext.so/gcc/debug/shared-linkable-true>properties_ext.so for lack of <@boost!libs!python!test/properties_ext.so/gcc/debug/shared-linkable-true>properties.o... ...failed gcc-C++-action ../../../bin/boost/libs/python/test/crossmod_exception_a.so/gcc/debug/shared-linkable-true/crossmod_exception_a.o... ...skipped <@boost!libs!python!test/crossmod_exception_a.so/gcc/debug/shared-linkable-true>crossmod_exception_a.so for lack of <@boost!libs!python!test/crossmod_exception_a.so/gcc/debug/shared-linkable-true>crossmod_exception_a.o... ...failed gcc-C++-action ../../../bin/boost/libs/python/test/crossmod_exception_b.so/gcc/debug/shared-linkable-true/crossmod_exception_b.o... ...skipped <@boost!libs!python!test/crossmod_exception_b.so/gcc/debug/shared-linkable-true>crossmod_exception_b.so for lack of <@boost!libs!python!test/crossmod_exception_b.so/gcc/debug/shared-linkable-true>crossmod_exception_b.o... ...failed gcc-Link-action ../../../bin/boost/libs/python/test/select_arg_to_python_test.test/gcc/debug/threading-multi/select_arg_to_python_test... ...failed gcc-C++-action ../../../bin/boost/libs/python/test/embedding.test/gcc/debug/threading-multi/embedding.o... ...skipped <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding for lack of <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding.o...
--- Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
Thanks for runnung those tests! I got your tarball, unpacked it, and ran bjam in libs/python/test on * SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE Python 2.3.3 as shipped by SuSE and * SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE Python 2.3.3 from www.python.org as before.
Results :
...failed updating 2 targets... ...skipped 1 target... ...updated 492 targets...
The exact same failures are reported under Red Hat 8.0 with gcc 3.2, a configuration which is definitely not affected by the patch. I.e. the failures must be unrelated. Your patch is in CVS now. If you get a chance could you do me a little favor and try this under SuSE 9.x? mkdir /var/tmp/junk cd /var/tmp/junk wget http://cci.lbl.gov/cctbx_build/results/2004_07_08_1744/cctbx_bundle.selfx perl cctbx_bundle.selfx The last command will prompt you for the number of available CPU's and then start building Boost.Python and a large number of extension modules. I am just interested to know if it goes through without errors (it does so on at least 13 other platforms). To remove all traces of the test simply rm -rf /var/tmp/junk. It will take about 1 CPU hour for everything to compile so you might want to start the build before you go home. Please disregard my request without comment if there are any issues. Thanks, Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
On Thu, 8 Jul 2004, Ralf W. Grosse-Kunstleve wrote:
The exact same failures are reported under Red Hat 8.0 with gcc 3.2, a configuration which is definitely not affected by the patch. I.e. the failures must be unrelated. Your patch is in CVS now.
Great. Thanks!
If you get a chance could you do me a little favor and try this under SuSE 9.x?
mkdir /var/tmp/junk cd /var/tmp/junk wget http://cci.lbl.gov/cctbx_build/results/2004_07_08_1744/cctbx_bundle.selfx perl cctbx_bundle.selfx
The last command will prompt you for the number of available CPU's and then start building Boost.Python and a large number of extension modules. I am just interested to know if it goes through without errors (it does so on at least 13 other platforms).
I built your bundle on both SuSE 9.0 and SuSE 9.1. The build ends with running a selected test followed by instructions on how to use the installation in a new shell or process. This presumably indicates that no errrors occured. :-) Chris.
--- Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
I built your bundle on both SuSE 9.0 and SuSE 9.1. The build ends with running a selected test followed by instructions on how to use the installation in a new shell or process. This presumably indicates that no errrors occured. :-)
Yes! Thank you very much for trying this out. Just two days ago one of our users got stomped by the SuSE gcc problem. I am very glad we have a workaround now. Thanks for your persistence! Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
The exact same failures are reported under Red Hat 8.0 with gcc 3.2, a configuration which is definitely not affected by the patch. I.e. the failures must be unrelated. Your patch is in CVS now.
I find these failures disturbing. Anyone have a clue? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
thanks for the pointers. Unfortunately I was unable to find a macro which would allow to decide whether the gcc-version used was patched by SuSE. So I guess, that for the time being I have to (a) install an 'official' gcc release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and gcc-3.4.0 seemes to indicate that neither minds the added reference. Should they?
That's beyond me... David, I still think it is not ideal that Boost.Python doesn't work out-of-the box under SuSE 9.x. What do you think about this plan: First we verify that the unpatched gcc's don't choke on the added reference. If that works out we add the reference under a condition like this (reformulated using BOOST_WORKAROUND): #if defined(__linux__) && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3 && (__GNUC_PATCHLEVEL__ == 1 || __GNUC_PATCHLEVEL__ == 3) Would that be acceptable? I could test with the gcc versions under question under RedHat. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Hi Chris, Thanks for letting me know how you've gotten it to work. I'll try including the individual Boost.Python headers instead of <boost/python.hpp>. As I mentioned in my response to Ralf, if you compile a compatible gcc (3.3.1 for SUSE 9.0) and install it into /usr/local, including <boost/python.hpp> works. Chad On Fri, 25 Jun 2004 11:29:31 +0200 (CEST), Chris Hoeppler <hoeppler@diener.iap.physik.uni-tuebingen.de> wrote:
On Tue, 22 Jun 2004, Chad Austin wrote:
Hi all,
Has anyone successfully used Boost.Python in SUSE 9.0 or SUSE 9.1? In 9.0 I had to build and install boost 1.31 from source, but 9.1 comes with a boost 1.31 package. Either way, merely #including <boost/python.hpp> causes an internal compiler error in a variety of places. Note: SUSE 9.0 uses gcc 3.3.1 (+ SUSE-specific patches?) and SUSE 9.1 uses gcc 3.3.3 (+ patches again?). If I build gcc 3.4.0 from source, Boost.Python compiles, but does not link do to incompatibilities in libstdc++. I'm going to try Boost.Python from CVS before anything else, but I thought I'd ask if anyone else has had success or failure in this area.
Thanks, Chad
Hi,
I've managed to successfully compile and use a small module on SuSE 9.0 with the following setup:
* gcc version 3.3.1 (SuSE Linux)
* boost_1_31_0 obtained from boost site and compiled from sources
* python 2.3.3 also compiled from sources.
* Module:
#include <boost/python/suite/indexing/vector_indexing_suite.hpp> #include <boost/python/module.hpp> #include <boost/python/def.hpp> #include <boost/python/implicit.hpp>
#include "rpower.h"
using namespace boost::python;
BOOST_PYTHON_MODULE(fftw_ext) { class_<std::vector<fftw_real> >("fftw_realVec") .def(vector_indexing_suite<std::vector<fftw_real> >()) ;
def("power_spectrum", power_spectrum); }
where power_spectrum is a function defined in rpower.h with the following signature:
void power_spectrum(std::vector<fftw_real> &in, std::vector<fftw_real> &out);
However, I've just tried to compile a test file with just one line #include <boost/python.hpp> as mentioned in your post quoted above, which also results in an internal compiler error:
g++ -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -g -O0 \ -fno-inline -fPIC -DDEBUG -I/usr/local/include/python2.3 \ -I/usr/local/include/boost-1_31 -c -o test.os test.cpp
<snipped warning about _POSIX_C_SOURCE being redefined> /usr/local/include/boost-1_31/boost/python/object_core.hpp:283: internal compiler error: Segmentation fault
Any clues on how to proceed from here?
Thanks, Chris
_______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
participants (5)
-
Chad Austin -
Chris Hoeppler -
David Abrahams -
Jonathan Brandmeyer -
Ralf W. Grosse-Kunstleve