Hello! Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. The problem is illustrated by the following example: ---%<--- #include <iostream> using namespace std; template <typename T> void foo(T const &x) { cout << "1" << endl; } template <typename T> void foo(T * const &x) { cout << "2" << endl; } int main() { foo("abc"); return 0; } --->%--- This prints out "2" with the default name mangling scheme. When manually selecting "ansi" as the name mangling scheme, the correct result "1" is printed. Therefore I propose to explicitely set the name mangling to ansi in the tools file for this compiler. Does anyone have any strong feelings or arguments against such a change? Markus
Markus Schöpflin wrote:
Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. ... Therefore I propose to explicitely set the name mangling to ansi in the tools file for this compiler. Does anyone have any strong feelings or arguments against such a change?
Wouldn't this force users to compile all of their code with nondefault name mangling? I would prefer that the docs include some warnings about the problem, with instructions about how to alter the name mangling. Making nondefault compiler behavior the default for using boost places a burden on the users rather than making it easier for them. Instead, just make sure it's easy for users that are already using the alternate name mangling to configure boost for it. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Markus Schöpflin wrote:
Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. ... Therefore I propose to explicitely set the name mangling to ansi in the tools file for this compiler. Does anyone have any strong feelings or arguments against such a change?
Wouldn't this force users to compile all of their code with nondefault name mangling? I would prefer that the docs include some warnings about the problem, with instructions about how to alter the name mangling. Making nondefault compiler behavior the default for using boost places a burden on the users rather than making it easier for them.
To be precise, every user using a compiled boost (or any other C++) library has to compile and link his code with the same name mangling as the already compiled code.
Instead, just make sure it's easy for users that are already using the alternate name mangling to configure boost for it.
The problem is, currently there are numerous regression test failures due to the use of the old name mangling scheme, which go away when ansi name mangling is selected. Therefore I though it would be a better alternative to use the more working alternative and document that the old name mangling scheme gives troubles when used with boost. Markus
Markus Schöpflin wrote:
The problem is, currently there are numerous regression test failures due to the use of the old name mangling scheme, which go away when ansi name mangling is selected. Therefore I thought it would be a better alternative to use the more working alternative and document that the old name mangling scheme gives troubles when used with boost.
Having read the man page, as suggested by Ian McC, it's clear that '-model ansi' is the standard way to go. Since our tru64cxx65 days are numbered here, I will probably stick with Boost 1.31.0 for the duration. However, I would suggest a strong admonition (recommendation) in the docs about the desirability of using '-model ansi', justifying its use as the default, and an easy way for the user to configure Boost libraries with '-model arm'. (There may be applications that access shared libraries that cannot be recompiled.) -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Markus Schöpflin wrote:
The problem is, currently there are numerous regression test failures due to the use of the old name mangling scheme, which go away when ansi name mangling is selected. Therefore I thought it would be a better alternative to use the more working alternative and document that the old name mangling scheme gives troubles when used with boost.
Having read the man page, as suggested by Ian McC, it's clear that '-model ansi' is the standard way to go. Since our tru64cxx65 days are numbered here, I will probably stick with Boost 1.31.0 for the duration.
You could still use the new version, you just would have to change the name mangling back to the old behaviour. (And of course hope that non of the libraries you are using is actually affected by the problem.)
However, I would suggest a strong admonition (recommendation) in the docs about the desirability of using '-model ansi', justifying its use as the default, and an easy way for the user to configure Boost libraries with '-model arm'. (There may be applications that access shared libraries that cannot be recompiled.)
What would you consider an easy way? Manually editing the toolset description would be out of the question I think, even if it's documented. Markus
Markus Schöpflin wrote:
What would you consider an easy way? Manually editing the toolset description would be out of the question I think, even if it's documented.
"Easy" would be one or two sentences; what to change in what file(s) would be o.k. I would expect to find the explanation and instructions in tools/build/v1/tru64cxx-tools.html. In fact, having looked at this short page, it brings up another possibility. Changing the name mangling is like using a different compiler, or a different version of the compiler with a change in its ABI. How about a different toolset? You are welcome to change tru64cxx65 to use -model ansi, and create a new tru64cxx65arm for -model arm. This would highlight the problem for new users. It would also make it easier for Boost developers to diagnose problems, because both options would be recognized, rather than leaving one unsupported. Even if tests fail for tru64cxx65arm, the failures would be understood. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Markus Schöpflin wrote:
What would you consider an easy way? Manually editing the toolset description would be out of the question I think, even if it's documented.
"Easy" would be one or two sentences; what to change in what file(s) would be o.k. I would expect to find the explanation and instructions in tools/build/v1/tru64cxx-tools.html.
In fact, having looked at this short page, it brings up another possibility. Changing the name mangling is like using a different compiler, or a different version of the compiler with a change in its ABI. How about a different toolset? You are welcome to change tru64cxx65 to use -model ansi, and create a new tru64cxx65arm for -model arm. This would highlight the problem for new users.
It would also make it easier for Boost developers to diagnose problems, because both options would be recognized, rather than leaving one unsupported. Even if tests fail for tru64cxx65arm, the failures would be understood.
To speak in terms of boost.build, this could be done as a build feature. We could add a new build feature called "name-mangling" with the values "arm" and "ansi". This would give you the opportunity to use bjam -sBUILD="debug <name-mangling>ansi" or -sBUILD="debug <name-manling>arm". As a default I would suggest to use ansi then. What do you think? Markus
Markus Schöpflin wrote:
To speak in terms of boost.build, this could be done as a build feature. We could add a new build feature called "name-mangling" with the values "arm" and "ansi". This would give you the opportunity to use bjam -sBUILD="debug <name-mangling>ansi" or -sBUILD="debug <name-manling>arm". As a default I would suggest to use ansi then.
That sounds fine, and it's easy to use. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Markus Schöpflin wrote:
Hello!
Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. The problem is illustrated by the following example:
---%<--- #include <iostream> using namespace std;
template <typename T> void foo(T const &x) { cout << "1" << endl; }
template <typename T> void foo(T * const &x) { cout << "2" << endl; }
int main() { foo("abc"); return 0; } --->%---
This prints out "2" with the default name mangling scheme. When manually selecting "ansi" as the name mangling scheme, the correct result "1" is printed.
Therefore I propose to explicitely set the name mangling to ansi in the tools file for this compiler. Does anyone have any strong feelings or arguments against such a change?
probably "-model ansi" is sufficient, and IMO absolutely necessary. IIRC correctly, there are issues with class-scope enumerations colliding, and in the past I also had a problem with non-type template parameters that I can't remember the details of just now.
From the cxx man page:
-model [ansi | arm] [Tru64] Determines the layout of C++ classes, name mangling, and exception handling. On Tru64 UNIX, the default is -model arm; on Linux Alpha, the default is -model ansi. The -model arm option is not supported on Linux Alpha. The -model arm option is the default and generates objects that are link compatible with all Compaq C++ releases prior to Version 6.3, and with all objects compiled using the -model arm option in Compaq C++ Version 6.3 or later. Specifying this option defines the macro __MODEL_ARM. The -model ansi option supports the complete ISO/ANSI C++ specification, including distinct name mangling for templates. The ANSI model also reduces the size of C++ non-POD class objects. Note that this option generates objects that are not compatible with prior releases of Compaq C++, or with objects compiled using the -model arm option. If you specify the -model ansi option, you must recompile your entire application, including libraries. Specifying this option defines the macro __MODEL_ANSI. HTH, Ian McCulloch
Ian McCulloch wrote:
probably "-model ansi" is sufficient, and IMO absolutely necessary.
That's what I intended to do. Add -model ansi to both the compiler and linker options. And of course update the documentation.
IIRC correctly, there are issues with class-scope enumerations colliding, and in the past I also had a problem with non-type template parameters that I can't remember the details of just now.
I wasn't aware of those.
From the cxx man page:
-model [ansi | arm]
[Tru64] Determines the layout of C++ classes, name mangling, and exception handling. On Tru64 UNIX, the default is -model arm; on Linux Alpha, the default is -model ansi. The -model arm option is not supported on Linux Alpha.
The -model arm option is the default and generates objects that are link compatible with all Compaq C++ releases prior to Version 6.3, and with all objects compiled using the -model arm option in Compaq C++ Version 6.3 or later. Specifying this option defines the macro __MODEL_ARM.
The -model ansi option supports the complete ISO/ANSI C++ specification, including distinct name mangling for templates. The ANSI model also reduces the size of C++ non-POD class objects. Note that this option generates objects that are not compatible with prior releases of Compaq C++, or with objects compiled using the -model arm option.
If you specify the -model ansi option, you must recompile your entire application, including libraries. Specifying this option defines the macro __MODEL_ANSI.
In theory we could even provide workarounds depending on which macro is defined. IIRC, there are some workarounds to that effect in the python library. I think those should be wrapped in something like #if using Compaq C++ and __MODEL_ARM is defined ... #endif. Markus
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
Hello!
Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. The problem is illustrated by the following example:
---%<--- #include <iostream> using namespace std;
template <typename T> void foo(T const &x) { cout << "1" << endl; }
template <typename T> void foo(T * const &x) { cout << "2" << endl; }
int main() { foo("abc"); return 0; } --->%---
This prints out "2" with the default name mangling scheme. When manually selecting "ansi" as the name mangling scheme, the correct result "1" is printed.
Therefore I propose to explicitely set the name mangling to ansi in the tools file for this compiler. Does anyone have any strong feelings or arguments against such a change?
No strong feelings, just selfish worries. I am usually compiling with -std strict_ansi. Is that automatically giving me the "ansi" name mangling scheme? Which switches do you want to add to the toolset? Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
Ralf W. Grosse-Kunstleve wrote:
No strong feelings, just selfish worries.
Understood. That's why I was asking in the first place... ;-)
I am usually compiling with -std strict_ansi. Is that automatically giving me the "ansi" name mangling scheme?
Surprisingly not.
Which switches do you want to add to the toolset?
-model ansi (But see my answer to Richard Hadsell's last note.) Markus
--- Markus_Sch�pflin <markus.schoepflin@epost.de> wrote:
Which switches do you want to add to the toolset?
-model ansi
Using cxx V6.5-031, Boost.Python doesn't build with -model ansi. I get heaps of "unresolved symbol" errors. Now installing the latest compiler... Ralf _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Ralf W. Grosse-Kunstleve wrote:
--- Markus_Schöpflin <markus.schoepflin@epost.de> wrote:
Which switches do you want to add to the toolset?
-model ansi
Using cxx V6.5-031, Boost.Python doesn't build with -model ansi. I get heaps of "unresolved symbol" errors. Now installing the latest compiler... Ralf
As a side note. Do you also get the following warnings when compiling boost.python for this platform on each and every file: cxx: Warning: /net/camos/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h, line 840: #47-D incompatible redefinition of macro "_OSF_SOURCE" (declared at line 223 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /net/camos/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h, line 847: #47-D incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 213 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /net/camos/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h, line 859: #47-D incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 203 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^ Markus
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
As a side note. Do you also get the following warnings when compiling boost.python for this platform on each and every file:
cxx: Warning: /net/camos/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h, line 840: #47-D incompatible redefinition of macro "_OSF_SOURCE" (declared at line 223 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /net/camos/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h, line 847: #47-D incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 213 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /net/camos/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h, line 859: #47-D incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 203 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^
No. I just checked out the very latest Boost CVS (ca. 3pm PDT) and all of Boost.Python (library and tests) compiles without showing your warnings above. I just get two different, short warnings. My compile flags are: cxx -model ansi -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DNDEBUG -O2 -fast Linking: cxx -model ansi -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*' Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail
Ralf W. Grosse-Kunstleve wrote:
No. I just checked out the very latest Boost CVS (ca. 3pm PDT) and all of Boost.Python (library and tests) compiles without showing your warnings above. I just get two different, short warnings. My compile flags are:
cxx -model ansi -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DNDEBUG -O2 -fast
Linking:
cxx -model ansi -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*'
Strange. Which version of python are you using exactly? And do you know how your python installation was cofigured? Markus
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
Ralf W. Grosse-Kunstleve wrote:
No. I just checked out the very latest Boost CVS (ca. 3pm PDT) and all of Boost.Python (library and tests) compiles without showing your warnings above. I just get two different, short warnings. My compile flags are:
cxx -model ansi -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DNDEBUG -O2 -fast
Linking:
cxx -model ansi -shared -expect_unresolved 'Py*' -expect_unresolved '_Py*'
Strange. Which version of python are you using exactly? And do you know how your python installation was cofigured?
I was using Python 2.3.4. It was configured without any special options except for --prefix=/usr/local_cci/Python-2.3.4. A year ago or so David and I spent a lot of time rearranging the include statements in Boost.Python to avoid the warnings you reported. I have no idea why they still appear in your build. Ralf _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Ralf W. Grosse-Kunstleve wrote:
--- Markus_Schöpflin <markus.schoepflin@comsoft.de> wrote:
A year ago or so David and I spent a lot of time rearranging the include statements in Boost.Python to avoid the warnings you reported. I have no idea why they still appear in your build.
When looking at the include statements, I have no idea why these warnings don't happen in _your_ build. :-) Seriously, the problem is, that <limits.h> is included before <Python.h>. <limits.h> itself includes <standards.h> which sets (for example) _XOPEN_SOURCE to 500 as a default, if nothing is specified. But <Python.h> includes <pyconfig.h> which sets _XOPEN_SOURCE to 600. I know that boost.python is aware of the issue (see comments in "python/detail/prefix.hpp") but I don't understand how the workaround is supposed to work. :-( IMO, at least <pyconfig.h> _must_ be included before _any_ system header. Everything else is asking for trouble... Markus
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
Ralf W. Grosse-Kunstleve wrote:
--- Markus_Schöpflin <markus.schoepflin@comsoft.de> wrote: A year ago or so David and I spent a lot of time rearranging the include statements in Boost.Python to avoid the warnings you reported. I have no idea why they still appear in your build.
When looking at the include statements, I have no idea why these warnings don't happen in _your_ build. :-)
Seriously, the problem is, that <limits.h> is included before <Python.h>. <limits.h> itself includes <standards.h> which sets (for example) _XOPEN_SOURCE to 500 as a default, if nothing is specified. But <Python.h> includes <pyconfig.h> which sets _XOPEN_SOURCE to 600.
I know that boost.python is aware of the issue (see comments in "python/detail/prefix.hpp") but I don't understand how the workaround is supposed to work. :-( IMO, at least <pyconfig.h> _must_ be included before _any_ system header. Everything else is asking for trouble...
I'm willing to try any change you think is appropriate. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
I'm willing to try any change you think is appropriate.
Attached is a patch which fixes the problem on my system. Given the complexity of the matter, I can make no promises for other systems. Maybe we could check it in and see what happens with the regression tests? Markus Index: wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.18 diff -u -r1.18 wrap_python.hpp --- wrap_python.hpp 26 Jul 2004 00:32:07 -0000 1.18 +++ wrap_python.hpp 31 Aug 2004 15:52:05 -0000 @@ -21,6 +21,23 @@ // 01 Mar 01 define PyObject_INIT() for Python 1.x (Dave Abrahams) // +// Get ahold of Python's version number +// +#include <patchlevel.h> + +// +// Include the python config file. This has to be done before including any +// system headers because it defines macros which might collide with default +// definitions. Namely these are _OSF_SOURCE, _POSIX_C_SOURCE, and +// _XOPEN_SOURCE. +// +#if PY_MAJOR_VERSION < 2 || PY_MAJOR_VERSION == 2 && PY_MINOR_VERSION < 2 +# include <config.h> +#else +# include <pyconfig.h> +#endif + +// // Python's LongObject.h helpfully #defines ULONGLONG_MAX for us, // which confuses Boost's config // @@ -35,11 +52,6 @@ # define BOOST_PYTHON_ULONGLONG_MAX_UNDEFINED #endif -// -// Get ahold of Python's version number -// -#include <patchlevel.h> - #ifdef _DEBUG # ifndef BOOST_DEBUG_PYTHON # undef _DEBUG // Don't let Python force the debug library just because we're debugging.
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
David Abrahams wrote:
I'm willing to try any change you think is appropriate.
Attached is a patch which fixes the problem on my system. Given the complexity of the matter, I can make no promises for other systems. Maybe we could check it in and see what happens with the regression tests?
Please go ahead. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
David Abrahams wrote:
I'm willing to try any change you think is appropriate.
Attached is a patch which fixes the problem on my system. Given the complexity of the matter, I can make no promises for other systems. Maybe we could check it in and see what happens with the regression tests?
Markus
I just started a local test run after inserting #include <pyconfig.h> at the beginning of prefix.hpp. It will take a few hours before I have all results.
Index: wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.18 diff -u -r1.18 wrap_python.hpp --- wrap_python.hpp 26 Jul 2004 00:32:07 -0000 1.18 +++ wrap_python.hpp 31 Aug 2004 15:52:05 -0000 @@ -21,6 +21,23 @@ // 01 Mar 01 define PyObject_INIT() for Python 1.x (Dave Abrahams)
// +// Get ahold of Python's version number +// +#include <patchlevel.h> + +// +// Include the python config file. This has to be done before including any +// system headers because it defines macros which might collide with default +// definitions. Namely these are _OSF_SOURCE, _POSIX_C_SOURCE, and +// _XOPEN_SOURCE. +// +#if PY_MAJOR_VERSION < 2 || PY_MAJOR_VERSION == 2 && PY_MINOR_VERSION < 2 +# include <config.h> +#else +# include <pyconfig.h> +#endif
Boost.Python Version 2 requires Python 2.2 or greater anyway. I think we should eliminate this complicated construct. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Ralf W. Grosse-Kunstleve wrote:
I just started a local test run after inserting #include <pyconfig.h> at the beginning of prefix.hpp. It will take a few hours before I have all results.
Do you suggest that adding <pyconfig.h> to prefix.hpp instead of wrap_python.hpp would be the way to go?
+// Include the python config file. This has to be done before including any +// system headers because it defines macros which might collide with default +// definitions. Namely these are _OSF_SOURCE, _POSIX_C_SOURCE, and +// _XOPEN_SOURCE. +// +#if PY_MAJOR_VERSION < 2 || PY_MAJOR_VERSION == 2 && PY_MINOR_VERSION < 2 +# include <config.h> +#else +# include <pyconfig.h> +#endif
Boost.Python Version 2 requires Python 2.2 or greater anyway.
What about a check in this file, then? Something like #if PY_MAJOR_VERSION<2 || PY_MAJOR_VERSION==2 && PY_MINOR_VERSION<2 #error ... #endif
I think we should eliminate this complicated construct.
It was taken from further down the file. That should go as well, then. Markus
--- Markus_Sch�pflin <markus.schoepflin@epost.de> wrote:
Ralf W. Grosse-Kunstleve wrote:
I just started a local test run after inserting #include <pyconfig.h> at the beginning of prefix.hpp. It will take a few hours before I have all results.
Do you suggest that adding <pyconfig.h> to prefix.hpp instead of wrap_python.hpp would be the way to go?
It seems most natural to me, but it's really a matter of taste I guess. The tests are going well. Only one platform is not yet completely done (a really old SGI). The newer SGI compiler (7.41) had a hick-up. <complex> has to be included before pyconfig.h to avoid hard errors. I'll look at this some more ASAP. Maybe this one exception to the "pyconfig.h first" rule can be avoided somehow.
Boost.Python Version 2 requires Python 2.2 or greater anyway.
What about a check in this file, then? Something like
#if PY_MAJOR_VERSION<2 || PY_MAJOR_VERSION==2 && PY_MINOR_VERSION<2 #error ... #endif
Yes, that looks like a good idea to me. I'll include it in my patched version of wrap_python.hpp.
I think we should eliminate this complicated construct.
It was taken from further down the file. That should go as well, then.
Yes, I've locally removed both instances. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Ralf W. Grosse-Kunstleve wrote:
Yes, that looks like a good idea to me. I'll include it in my patched version of wrap_python.hpp.
If you're done with the test runs, just go ahead and apply the patches yourself. That would be best, I think. Markus
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
Ralf W. Grosse-Kunstleve wrote:
Yes, that looks like a good idea to me. I'll include it in my patched version of wrap_python.hpp.
If you're done with the test runs, just go ahead and apply the patches yourself. That would be best, I think.
The two patches below are now in CVS. Thanks Markus for your help! I've tested with a fairly large variety of compilers, but not VC6, VC7.0 or any Codewarrior. We should keep an eye on the Metacomm logs. I hope this is the end of our struggle with the "Python.h first" requirement. Cheers, Ralf Index: prefix.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/prefix.hpp,v retrieving revision 1.3 diff -u -r1.3 prefix.hpp --- prefix.hpp 26 Jul 2004 00:32:07 -0000 1.3 +++ prefix.hpp 1 Sep 2004 09:11:38 -0000 @@ -9,8 +9,11 @@ // headers (so it can get control over some awful macros). // Unfortunately, Boost.Python needs to #include <limits.h> first, at // least... but this gets us as close as possible. + +# include <pyconfig.h> # if defined(_SGI_COMPILER_VERSION) && _SGI_COMPILER_VERSION == 741 -# include <complex> +# undef _POSIX_C_SOURCE +# undef _XOPEN_SOURCE # endif # include <boost/python/detail/wrap_python.hpp> # include <boost/python/detail/config.hpp> Index: wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.18 diff -u -r1.18 wrap_python.hpp --- wrap_python.hpp 26 Jul 2004 00:32:07 -0000 1.18 +++ wrap_python.hpp 1 Sep 2004 09:11:38 -0000 @@ -40,6 +40,10 @@ // #include <patchlevel.h> +#if PY_MAJOR_VERSION<2 || PY_MAJOR_VERSION==2 && PY_MINOR_VERSION<2 +#error Python 2.2 or higher is required for this version of Boost.Python. +#endif + #ifdef _DEBUG # ifndef BOOST_DEBUG_PYTHON # undef _DEBUG // Don't let Python force the debug library just because we're debugging. @@ -96,19 +100,9 @@ # define _MSC_VER 900 # endif -# if PY_MAJOR_VERSION < 2 || PY_MAJOR_VERSION == 2 && PY_MINOR_VERSION < 2 -# include <config.h> -# else -# include <pyconfig.h> -# endif # undef hypot // undo the evil #define left by Python. # elif defined(__BORLANDC__) -# if PY_MAJOR_VERSION < 2 || PY_MAJOR_VERSION == 2 && PY_MINOR_VERSION < 2 -# include <config.h> -# else -# include <pyconfig.h> -# endif # undef HAVE_HYPOT # define HAVE_HYPOT 1 # endif _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Ralf W. Grosse-Kunstleve wrote:
The two patches below are now in CVS. Thanks Markus for your help! I've tested with a fairly large variety of compilers, but not VC6, VC7.0 or any Codewarrior. We should keep an eye on the Metacomm logs.
I hope this is the end of our struggle with the "Python.h first" requirement.
Just a small note. The version check in wrap_python.h now is essentially a no-op, because you're including <pyconfig.h> before in prefix.hpp. As the python config file was called <config.h> before version 2.2, it wouldn't compile anyway for older python versions. May I suggest to move the inclusion of <pyconfig.h> after the inclusion of <patchlevel.h> in wrap_python? Or move the version check to prefix.hpp. Just an idea... Markus
--- Markus_Sch�pflin <markus.schoepflin@epost.de> wrote:
Ralf W. Grosse-Kunstleve wrote:
The two patches below are now in CVS. Thanks Markus for your help! I've tested with a fairly large variety of compilers, but not VC6, VC7.0 or any Codewarrior. We should keep an eye on the Metacomm logs.
I hope this is the end of our struggle with the "Python.h first" requirement.
Just a small note. The version check in wrap_python.h now is essentially a no-op, because you're including <pyconfig.h> before in prefix.hpp. As the python config file was called <config.h> before version 2.2, it wouldn't compile anyway for older python versions.
Good point, but it is a bit more than a no-op: % g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -ffast-math -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/worm/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-1.5.2/include/python1.5 -c -o boost/libs/python/src/converter/builtin_converters.os /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp In file included from /net/worm/scratch1/rwgk/hot/boost/boost/python/handle.hpp:8, from /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:6: /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/prefix.hpp:13:23: pyconfig.h: No such file or directory In file included from /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/prefix.hpp:18, from /net/worm/scratch1/rwgk/hot/boost/boost/python/handle.hpp:8, from /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:6: /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/wrap_python.hpp:44:2: #error Python 2.2 or higher is required for this version of Boost.Python. In file included from /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:12: /net/worm/scratch1/rwgk/hot/boost/boost/python/detail/wrap_python.hpp:44:2: #error Python 2.2 or higher is required for this version of Boost.Python. In file included from /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:14: /net/worm/scratch1/rwgk/hot/boost/boost/python/converter/builtin_converters.hpp: In member function `PyObject* boost::python::to_python_value<std::wstring&>::operator()(const std::wstring&) const': /net/worm/scratch1/rwgk/hot/boost/boost/python/converter/builtin_converters.hpp:116: `:: PyUnicode_FromWideChar' undeclared (first use here) /net/worm/scratch1/rwgk/hot/boost/boost/python/converter/builtin_converters.hpp: In constructor `boost::python::converter::arg_to_python<std::wstring>::arg_to_python(const std::wstring&)': /net/worm/scratch1/rwgk/hot/boost/boost/python/converter/builtin_converters.hpp:116: `:: PyUnicode_FromWideChar' undeclared (first use here) /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp: In function `PyObject* boost::python::converter::<unnamed>::encode_string_unaryfunc(PyObject*)': /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:278: ` PyUnicode_FromEncodedObject' undeclared (first use this function) /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:278: (Each undeclared identifier is reported only once for each function it appears in.) /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp: In static member function `static PyObject*(** boost::python::converter::<unnamed>::wstring_rvalue_from_python::get_slot(PyObject*))(PyObject*)': /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:290: ` PyUnicode_Check' undeclared (first use this function) /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp: In static member function `static std::wstring boost::python::converter::<unnamed>::wstring_rvalue_from_python::extract(PyObject*)': /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:302: ` PyUnicodeObject' undeclared (first use this function) /net/worm/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp:302: parse error before `;' token
May I suggest to move the inclusion of <pyconfig.h> after the inclusion of <patchlevel.h> in wrap_python? Or move the version check to prefix.hpp. Just an idea...
The #error is not the first error message, but it appears in the output. That should be enough of a clue. I am not keen including patchlevel.h (or any other file) before pyconfig.h even though it will most likely be fine. On the other hand it is becoming more and more unlikely that anybody still has Python 2.1 or earlier. So why take chances? Considering all this I arrive at the conclusion that we should leave the includes as they are until we encounter a real problem. Cheers, Ralf _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
Ralf W. Grosse-Kunstleve wrote:
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
A year ago or so David and I spent a lot of time rearranging the include statements in Boost.Python to avoid the warnings you reported. I have no idea why they still appear in your build.
When looking at the include statements, I have no idea why these warnings don't happen in _your_ build. :-)
Well, I am just glad they don't...
Seriously, the problem is, that <limits.h> is included before <Python.h>. <limits.h> itself includes <standards.h> which sets (for example) _XOPEN_SOURCE to 500 as a default, if nothing is specified. But <Python.h> includes <pyconfig.h> which sets _XOPEN_SOURCE to 600.
I know that boost.python is aware of the issue (see comments in "python/detail/prefix.hpp") but I don't understand how the workaround is supposed to work. :-( IMO, at least <pyconfig.h> _must_ be included before _any_ system header. Everything else is asking for trouble...
True. I am wondering now why we didn't do this. I see that pyconfig.h in the Python versions 2.2.1 and 2.3.4 at least doesn't include any other files. What happens on your platform if you add #include <pyconfig.h> to the beginning of prefix.hpp? Ralf __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
Ralf W. Grosse-Kunstleve wrote:
True. I am wondering now why we didn't do this. I see that pyconfig.h in the Python versions 2.2.1 and 2.3.4 at least doesn't include any other files. What happens on your platform if you add #include <pyconfig.h> to the beginning of prefix.hpp?
The warnings go away. I cannot say yet whether the tests succeed. Markus
--- Markus_Sch�pflin <markus.schoepflin@epost.de> wrote:
Which switches do you want to add to the toolset?
-model ansi
I just installed the latest cxx version, V6.5-041 from July 2004. Unfortunately the "unresolved symbol" messages persist, at least when compiling with -std strict_ansi. Almost two years ago I reported this to (then) Compaq and they acknowledged it is the compiler's fault, but apparently nothing was done to resolve the problem. Looks like I will have to continue using the default (-model arm). :( Ralf _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
--- Markus_Sch�pflin <markus.schoepflin@epost.de> wrote:
Which switches do you want to add to the toolset?
-model ansi
Correction: the unresolved symbol errors disappear if I add -model ansi not only to the compilation command, but also the link command. My old bug report seems to have done something! Now testing everything we have which will take a while... Ralf __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
--- "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> wrote:
--- Markus_Sch�pflin <markus.schoepflin@epost.de> wrote:
Which switches do you want to add to the toolset?
-model ansi
Correction: the unresolved symbol errors disappear if I add -model ansi not only to the compilation command, but also the link command. My old bug report seems to have done something! Now testing everything we have which will take a while... Ralf
Almost everything works with -model ansi, with this one exception: % python boost/libs/python/test/polymorphism.py E.E... ====================================================================== ERROR: testReturnCpp (__main__.PolymorphTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/net/worm/scratch1/rwgk/dist/boost/libs/python/test/polymorphism.py", line 20, in testReturnCpp self.failUnlessEqual ('B::f()', a.f()) RuntimeError: unidentifiable C++ exception ====================================================================== ERROR: test_pure_virtual (__main__.PolymorphTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/net/worm/scratch1/rwgk/dist/boost/libs/python/test/polymorphism.py", line 58, in test_pure_virtual self.failUnlessEqual ('Q::f()', q.f()) RuntimeError: unidentifiable C++ exception ---------------------------------------------------------------------- Ran 6 tests in 0.008s FAILED (errors=2) The same test works when compiled without the -model switch. However, I guess this could be fixed somehow, and -model ansi is the way to go if it makes other errors disappear. I.e. I think -model ansi should be default in the toolset. Ralf _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Ralf W. Grosse-Kunstleve wrote:
--- Markus_Schöpflin <markus.schoepflin@epost.de> wrote:
Which switches do you want to add to the toolset?
-model ansi
Correction: the unresolved symbol errors disappear if I add -model ansi not only to the compilation command, but also the link command. My old bug report seems to have done something! Now testing everything we have which will take a while...
I was just going to tell you that but you have figured it out on your own... :-) BTW, I now have a patch for boost.build.v1 ready which implements the new feature. You can use it like this: bjam -sTOOLS=tru64cxx65 -sBUILD="<object-model>arm" or bjam -sTOOLS=tru64cxx65 -sBUILD="<object-model>ansi" with ansi being the default. I have chosen the name "object-model" (and not name-mangling) for the feature, because it changes more than just the name mangling, namely the layout of C++ classes and also exception handling. Markus
Markus Schöpflin wrote:
I have chosen the name "object-model" (and not name-mangling) for the feature, because it changes more than just the name mangling, namely the layout of C++ classes and also exception handling.
Good call. It also relates more clearly to the compiler's -model option. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
On 8/25/04 11:05 AM, "Markus Schöpflin" <markus.schoepflin@comsoft.de> wrote:
Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. The problem is illustrated by the following example:
---%<--- #include <iostream> using namespace std;
template <typename T> void foo(T const &x) { cout << "1" << endl; }
template <typename T> void foo(T * const &x) { cout << "2" << endl; }
int main() { foo("abc"); return 0; } --->%---
This prints out "2" with the default name mangling scheme. When manually selecting "ansi" as the name mangling scheme, the correct result "1" is printed.
Why is [1] the correct answer? The string has type "char const [4]". I thought that the array-to-pointer conversion will happen, turning the string to a "char const *", which will match [2] with "char" for "T". I'm guessing that you think the reference in [1] prevents the array-to-pointer conversion, so [1] is the better match with "char [4]" for "T". I am guessing your logic correctly? Does anyone know if [1] is supposed to be the right answer? (No need to petition to change to compiler settings to choose [1] if [2] is supposed to be the standard answer.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. The problem is illustrated by the following example:
---%<--- #include <iostream> using namespace std;
template <typename T> void foo(T const &x) { cout << "1" << endl; }
template <typename T> void foo(T * const &x) { cout << "2" << endl; }
int main() { foo("abc"); return 0; } --->%---
This prints out "2" with the default name mangling scheme. When manually selecting "ansi" as the name mangling scheme, the correct result "1" is printed.
Why is [1] the correct answer? The string has type "char const [4]". I thought that the array-to-pointer conversion will happen, turning the string to a "char const *", which will match [2] with "char" for "T". I'm guessing that you think the reference in [1] prevents the array-to-pointer conversion, so [1] is the better match with "char [4]" for "T".
I am guessing your logic correctly? Does anyone know if [1] is supposed to be the right answer? (No need to petition to change to compiler settings to choose [1] if [2] is supposed to be the standard answer.)
Have a look at the answer from Jonathan Wakely in the thread "algorithm / string / container regression failure on tru64cxx65". That should cover your question, I think. Markus
participants (7)
-
Daryle Walker -
David Abrahams -
Ian McCulloch -
Markus Schöpflin -
Markus Schöpflin -
Ralf W. Grosse-Kunstleve -
Richard Hadsell