Re: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
On 06/07/2011 09:59 AM, Lars Viklund wrote: On Tue, Jun 07, 2011 at 09:40:25AM +0200, Jérôme Laheurte wrote: Hello. I already asked this on StackOverflow but it doesn't seem to inspire many people. I managed to reduce my problem to a trivial extension module: On Windows XP SP3, if I build Boost 1.46.1 and then this extension with GCC 3.4.5 from an older version of Mingw, everything behaves as expected: Now if I rebuild both Boost and the module using a newer Mingw, with GCC 4.5.2, this happens: Any hint would be greatly appreciated. Typically, you need to use the same major flavor of toolchain to build Boost.Python and your extension as was used to build your Python. If the runtimes (and exception handling) differ, you'll get ODR violations on things like FILE* and error handling. What you're observing there is probably console output crashing when an error is printed. If the runtimes have different ideas of what constitutes a FILE* (which output is done through), you blow up good. This also includes using static runtimes to some extent. Alas, this does not seem to be the case. I managed to rebuild Python with GCC 4.5 after some minor modifications of the interpreter code, then rebuilt boost and my extension. The same thing happens (except that the call stack is more detailed since the "upper" layers now have GCC debugging symbols). Besides, if I replace throw_error_already_set() by PyErr_Print(), the message is properly displayed; and on the other hand in my actual use case, it works with some methods. Still lost... ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
On 06/07/2011 09:59 AM, Lars Viklund wrote: On Tue, Jun 07, 2011 at 09:40:25AM +0200, Jérôme Laheurte wrote: Hello. I already asked this on StackOverflow but it doesn't seem to inspire many people. I managed to reduce my problem to a trivial extension module: On Windows XP SP3, if I build Boost 1.46.1 and then this extension with GCC 3.4.5 from an older version of Mingw, everything behaves as expected: Now if I rebuild both Boost and the module using a newer Mingw, with GCC 4.5.2, this happens: Any hint would be greatly appreciated. Typically, you need to use the same major flavor of toolchain to build Boost.Python and your extension as was used to build your Python. If the runtimes (and exception handling) differ, you'll get ODR violations on things like FILE* and error handling. What you're observing there is probably console output crashing when an error is printed. If the runtimes have different ideas of what constitutes a FILE* (which output is done through), you blow up good. This also includes using static runtimes to some extent. Alas, this does not seem to be the case. I managed to rebuild Python with GCC 4.5 after some minor modifications of the interpreter code, then rebuilt boost and my extension. The same thing happens (except that the call stack is more detailed since the "upper" layers now have GCC debugging symbols). Besides, if I replace throw_error_already_set() by PyErr_Print(), the message is properly displayed; and on the other hand in my actual use case, it works with some methods. Still lost... ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
Might this be a symbol visibility problem? Niall On 10 Jun 2011 at 14:16, Jérôme Laheurte wrote: > On 06/07/2011 09:59 AM, Lars Viklund wrote: > > > On Tue, Jun 07, 2011 at 09:40:25AM +0200, Jérôme Laheurte wrote: > >> Hello. I already asked this on StackOverflow but it doesn't seem to > >> inspire many people. I managed to reduce my problem to a trivial > >> extension module: > > > >> On Windows XP SP3, if I build Boost 1.46.1 and then this extension with > >> GCC 3.4.5 from an older version of Mingw, everything behaves as expected: > > > >> Now if I rebuild both Boost and the module using a newer Mingw, with GCC > >> 4.5.2, this happens: > > > >> Any hint would be greatly appreciated. > > > > Typically, you need to use the same major flavor of toolchain to build > > Boost.Python and your extension as was used to build your Python. > > > > If the runtimes (and exception handling) differ, you'll get ODR > > violations on things like FILE* and error handling. > > > > What you're observing there is probably console output crashing when an > > error is printed. If the runtimes have different ideas of what > > constitutes a FILE* (which output is done through), you blow up good. > > This also includes using static runtimes to some extent. > > Alas, this does not seem to be the case. I managed to rebuild Python > with GCC 4.5 after some minor modifications of the interpreter code, > then rebuilt boost and my extension. The same thing happens (except that > the call stack is more detailed since the "upper" layers now have GCC > debugging symbols). > > Besides, if I replace throw_error_already_set() by PyErr_Print(), the > message is properly displayed; and on the other hand in my actual use > case, it works with some methods. > > Still lost... > ___ > Cplusplus-sig mailing list > [email protected] > http://mail.python.org/mailman/listinfo/cplusplus-sig -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
On 06/10/2011 02:48 PM, Niall Douglas wrote: Might this be a symbol visibility problem? How can I check that ? I just tried #defining BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY in boost/python/detail/config.hpp and rebuilt the whole stuff but there's no difference. Thanks Jérôme Laheurte ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
On 10 Jun 2011 at 16:03, Jérôme Laheurte wrote: > > Might this be a symbol visibility problem? > > How can I check that ? I just tried #defining > BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY in boost/python/detail/config.hpp > and rebuilt the whole stuff but there's no difference. I have little experience of Mingw personally. If I want to build for Windows, I use MSVC :) On POSIX, older versions of the GCC runtime require you to always keep symbols which are used to throw exceptions as default visibility as they compare symbols by address not content. Newer GCC runtimes finally do what I said they should have done from the beginning which is to string compare the mangled symbol. If BPL is throwing an exception and the catch handler isn't being found like it ought to be, this suggests they've broken the above in the Mingw port of GCC somehow. It could also be a problem of stack corruption causing the unwind records to get corrupted. I can't be any more definite because how PE binaries use symbols differently to ELF kinda suggests that GCC surely isn't copying the POSIX GCC exception type matching system anyway. If you're really keen on continuing to use Mingw, I'd first suggest you see if you can duplicate the problem in Cygwin. If you can you'll get a much bigger audience. Then you'll need a very reduced example exhibiting the bug, one not including Boost. Then you'll need to come up with a patch to PE GCC to fix it and wait the whatever number of weeks to get it into mainline. Or you could stick with an older version of Mingw and wait till someone else fixes the problem. Or use MSVC. BTW, debugging exception throws is a royal PITA. There ought to be some debug code in the GCC runtime if I remember, you could try turning that on and it will print each stage of what it does when you throw and/or rethrow an exception. HTH, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
Le 10 juin 2011 à 17:00, Niall Douglas a écrit : > On 10 Jun 2011 at 16:03, Jérôme Laheurte wrote: > >>> Might this be a symbol visibility problem? >> >> How can I check that ? I just tried #defining >> BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY in boost/python/detail/config.hpp >> and rebuilt the whole stuff but there's no difference. > > I have little experience of Mingw personally. If I want to build for > Windows, I use MSVC :) > > On POSIX, older versions of the GCC runtime require you to always > keep symbols which are used to throw exceptions as default visibility > as they compare symbols by address not content. Newer GCC runtimes > finally do what I said they should have done from the beginning which > is to string compare the mangled symbol. > > If BPL is throwing an exception and the catch handler isn't being > found like it ought to be, this suggests they've broken the above in > the Mingw port of GCC somehow. It could also be a problem of stack > corruption causing the unwind records to get corrupted. I can't be > any more definite because how PE binaries use symbols differently to > ELF kinda suggests that GCC surely isn't copying the POSIX GCC > exception type matching system anyway. > > If you're really keen on continuing to use Mingw, I'd first suggest > you see if you can duplicate the problem in Cygwin. If you can you'll > get a much bigger audience. Then you'll need a very reduced example > exhibiting the bug, one not including Boost. Then you'll need to come > up with a patch to PE GCC to fix it and wait the whatever number of > weeks to get it into mainline. > > Or you could stick with an older version of Mingw and wait till > someone else fixes the problem. Or use MSVC. Not really an option; GCC 4 gave us a factor 3 performance improvement over GCC 3, which we really need, and we're not really MSVC people. > > BTW, debugging exception throws is a royal PITA. There ought to be > some debug code in the GCC runtime if I remember, you could try > turning that on and it will print each stage of what it does when you > throw and/or rethrow an exception. OK Thanks for all the tips. Basically, this is not a Boost issue so I'll have to follow the GCC bug track :) Jérôme Laheurte ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
> > Or you could stick with an older version of Mingw and wait till > > someone else fixes the problem. Or use MSVC. > > Not really an option; GCC 4 gave us a factor 3 performance improvement > over GCC 3, which we really need, and we're not really MSVC people. Ah that's a useful clue - I patched symbol visibility into what became GCC v4.0. I bet what's happened is that the PE outputting GCC doesn't have support for this new feature, or it's been borked. BTW MSVC is little different to GCC when used via the command line e.g. using Boost Jam, Makefiles or scons. It's also free of cost via Visual Studio Express. > > BTW, debugging exception throws is a royal PITA. There ought to be > > some debug code in the GCC runtime if I remember, you could try > > turning that on and it will print each stage of what it does when you > > throw and/or rethrow an exception. > > OK Thanks for all the tips. Basically, this is not a Boost issue so I'll > have to follow the GCC bug track :) Last time I was involved with GCC the PE backend was definitely low priority. I hope it's changed since, but since Visual Studio became free of charge a lot of fire has vanished from PE producing GCC. Best of luck, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
