Boost trunk on Solaris 10 sparc
Hello, I've made an attempt to build Boost from subversion trunk on Solaris 10 on sparc, with gcc-4.6.2. The build didn't succeed, and I'll be looking into ways to make it pass. I've recorded the build in log file which includes all the setup: http://buildfarm.opencsw.org/~maciej/boost-2012-02-29-09-51.log Some highlights: error: No best alternative for libs/context/build/asm_context_sources var/tmp//ccU7e2QF.s: Assembler messages: /var/tmp//ccU7e2QF.s:401: Error: Architecture mismatch on "cas". /var/tmp//ccU7e2QF.s:401: (Requires v9|v9a|v9b; requested architecture is v8.) /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/include-fixed/sys/feature_tests.h:341:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" In file included from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/bits/postypes.h:42:0, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/iosfwd:42, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/ios:39, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/ostream:40, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/iterator:64, from ./boost/next_prior.hpp:15, from ./boost/utility.hpp:17, from ./boost/python/instance_holder.hpp:10, from ./boost/python/object/pointer_holder.hpp:14, from ./boost/python/to_python_indirect.hpp:10, from ./boost/python/converter/arg_to_python.hpp:10, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object/enum_base.hpp:8, from libs/python/src/object/enum.cpp:6: There were a couple of other errors, they are in the log file. What the current status of Solaris builds? Is there anyone else building Boost on Solaris 10? Are any of the problems that are in the log file know and possible to work around? Maciej
Hi
error: No best alternative for libs/context/build/asm_context_sources
You need to setup a command line like this: (no idea what that would be on a sparc though, see the boost context thread I started a few days back). b2 toolset=msvc-10.0 architecture=x86 instruction-set=i386 address-model=32 Or you could not build boost.context entierly. Julien
Hello Maciej, unfortunately boost.context doesn't support the SPARC architecture yet. Maybe I find time soon to implement the assembler stuff for SPARC. regards, Oliver Am 02.03.2012 00:52, schrieb Maciej (Matchek) Bliziński:
Hello,
I've made an attempt to build Boost from subversion trunk on Solaris 10 on sparc, with gcc-4.6.2. The build didn't succeed, and I'll be looking into ways to make it pass. I've recorded the build in log file which includes all the setup:
http://buildfarm.opencsw.org/~maciej/boost-2012-02-29-09-51.log
Some highlights:
error: No best alternative for libs/context/build/asm_context_sources
var/tmp//ccU7e2QF.s: Assembler messages: /var/tmp//ccU7e2QF.s:401: Error: Architecture mismatch on "cas". /var/tmp//ccU7e2QF.s:401: (Requires v9|v9a|v9b; requested architecture is v8.)
/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/include-fixed/sys/feature_tests.h:341:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" In file included from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/bits/postypes.h:42:0, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/iosfwd:42, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/ios:39, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/ostream:40, from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../include/c++/4.6.2/iterator:64, from ./boost/next_prior.hpp:15, from ./boost/utility.hpp:17, from ./boost/python/instance_holder.hpp:10, from ./boost/python/object/pointer_holder.hpp:14, from ./boost/python/to_python_indirect.hpp:10, from ./boost/python/converter/arg_to_python.hpp:10, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object/enum_base.hpp:8, from libs/python/src/object/enum.cpp:6:
There were a couple of other errors, they are in the log file.
What the current status of Solaris builds? Is there anyone else building Boost on Solaris 10? Are any of the problems that are in the log file know and possible to work around?
Maciej
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Am 02.03.2012 19:16, schrieb Mathias Gaunard:
On 03/02/2012 03:08 PM, Oliver Kowalke wrote:
Hello Maciej, unfortunately boost.context doesn't support the SPARC architecture yet. Maybe I find time soon to implement the assembler stuff for SPARC. regards, Oliver
Couldn't it fall back to the ucontext implementation?
ucontext is deprecated by POSIX
On 03/02/2012 07:43 PM, Oliver Kowalke wrote:
Am 02.03.2012 19:16, schrieb Mathias Gaunard:
On 03/02/2012 03:08 PM, Oliver Kowalke wrote:
Hello Maciej, unfortunately boost.context doesn't support the SPARC architecture yet. Maybe I find time soon to implement the assembler stuff for SPARC. regards, Oliver
Couldn't it fall back to the ucontext implementation?
ucontext is deprecated by POSIX
Yet it's available on a large number of systems. It being removed from the POSIX specification doesn't mean systems will stop supporting it.
Am 02.03.2012 20:14, schrieb Mathias Gaunard:
On 03/02/2012 07:43 PM, Oliver Kowalke wrote:
Am 02.03.2012 19:16, schrieb Mathias Gaunard:
On 03/02/2012 03:08 PM, Oliver Kowalke wrote:
Hello Maciej, unfortunately boost.context doesn't support the SPARC architecture yet. Maybe I find time soon to implement the assembler stuff for SPARC. regards, Oliver
Couldn't it fall back to the ucontext implementation?
ucontext is deprecated by POSIX
Yet it's available on a large number of systems. It being removed from the POSIX specification doesn't mean systems will stop supporting it.
boost.context will use its own implementation
Thanks for your comments so far. Do you have any ideas about these error messages? 2012/3/1 Maciej (Matchek) Bliziński <maciej@opencsw.org>
/var/tmp//ccU7e2QF.s: Assembler messages: /var/tmp//ccU7e2QF.s:401: Error: Architecture mismatch on "cas". /var/tmp//ccU7e2QF.s:401: (Requires v9|v9a|v9b; requested architecture is v8.)
It sounds like there's assembler code which requires the v9 architecture, while v9 is 64-bit. To build 32-bit binaries, I need to build for the v8 (or v8+) architecture. Is that also related to boost.context? Maciej
Am 05.03.2012 11:31, schrieb Maciej (Matchek) Bliziński:
Thanks for your comments so far.
Do you have any ideas about these error messages?
2012/3/1 Maciej (Matchek) Bliziński<maciej@opencsw.org>
/var/tmp//ccU7e2QF.s: Assembler messages: /var/tmp//ccU7e2QF.s:401: Error: Architecture mismatch on "cas". /var/tmp//ccU7e2QF.s:401: (Requires v9|v9a|v9b; requested architecture is v8.) It sounds like there's assembler code which requires the v9 architecture, while v9 is 64-bit. To build 32-bit binaries, I need to build for the v8 (or v8+) architecture. Is that also related to boost.context?
Maciej
boost.context does not provide a SPARC implementation yet Oliver
Maciej (Matchek) Bliziński wrote:
2012/3/1 Maciej (Matchek) Bliziński <maciej@opencsw.org>
/var/tmp//ccU7e2QF.s: Assembler messages: /var/tmp//ccU7e2QF.s:401: Error: Architecture mismatch on "cas". /var/tmp//ccU7e2QF.s:401: (Requires v9|v9a|v9b; requested architecture is v8.)
It sounds like there's assembler code which requires the v9 architecture, while v9 is 64-bit. To build 32-bit binaries, I need to build for the v8 (or v8+) architecture.
This comes from shared_ptr, boost/smart_ptr/detail/sp_counted_base.hpp, line 59: #elif defined(__GNUC__) && ( defined( __sparcv9 ) || ( defined( __sparcv8 ) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 402 ) ) ) # include <boost/smart_ptr/detail/sp_counted_base_gcc_sparc.hpp> The problem here is that basically all Sparcs currently in existence support the V9 instruction set, but the GCC architecture macros denote an ABI and not an instruction set, and the V9 ABI is 64 bit. When you compile with -mcpu=v9 -m32, which enables the CAS instruction but still compiles for 32 bit and the V8 ABI, __sparcv8 is set. So there's no way to determine, on the basis of the predefined macros, whether shared_ptr should use CAS or not. The reason that the above line checks for GCC 4.2 or later is that 4.2+ should automatically build for the V9 ISA by default. However, it's possible that gcc.jam overrides this for some reason, as it contains, at line 1135: # Sparc cpu-flags gcc OPTIONS : sparc : c3 : -mcpu=c3 : default ; cpu-flags gcc OPTIONS : sparc : v7 : -mcpu=v7 ; cpu-flags gcc OPTIONS : sparc : cypress : -mcpu=cypress ; cpu-flags gcc OPTIONS : sparc : v8 : -mcpu=v8 ; cpu-flags gcc OPTIONS : sparc : supersparc : -mcpu=supersparc ; cpu-flags gcc OPTIONS : sparc : sparclite : -mcpu=sparclite ; cpu-flags gcc OPTIONS : sparc : hypersparc : -mcpu=hypersparc ; cpu-flags gcc OPTIONS : sparc : sparclite86x : -mcpu=sparclite86x ; cpu-flags gcc OPTIONS : sparc : f930 : -mcpu=f930 ; cpu-flags gcc OPTIONS : sparc : f934 : -mcpu=f934 ; cpu-flags gcc OPTIONS : sparc : sparclet : -mcpu=sparclet ; cpu-flags gcc OPTIONS : sparc : tsc701 : -mcpu=tsc701 ; cpu-flags gcc OPTIONS : sparc : v9 : -mcpu=v9 ; cpu-flags gcc OPTIONS : sparc : ultrasparc : -mcpu=ultrasparc ; cpu-flags gcc OPTIONS : sparc : ultrasparc3 : -mcpu=ultrasparc3 ; I have no idea what -mcpu=c3 does here, or why is it set as default. The default should be v9. c3 is the VIA C3, a x86 CPU. It's also possible that you've requested v8 explicitly, with instruction-set=v8. Change that to v9, if so. address-model=32 should still produce 32 bit binaries. Or, if you for some reason don't want to use V9 instructions, #define BOOST_SP_USE_PTHREADS.
2012/3/5 Peter Dimov <pdimov@pdimov.com>
The problem here is that basically all Sparcs currently in existence support the V9 instruction set, but the GCC architecture macros denote an ABI and not an instruction set, and the V9 ABI is 64 bit. When you compile with -mcpu=v9 -m32, which enables the CAS instruction but still compiles for 32 bit and the V8 ABI, __sparcv8 is set. So there's no way to determine, on the basis of the predefined macros, whether shared_ptr should use CAS or not.
Thanks for the explanation. I got it to build by specifying exactly that, -mcpu=v9 -m32, which resulted in v8+ binaries. For those interested, here's my set of Boost packages compiled on Solaris 10, for sparc and intel architectures: http://buildfarm.opencsw.org/experimental.html#boost Here's the build recipe: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/boost/branches/boos... Each shared library is in a separate package, so if you build something depending on Boost, you only need to depend on a small package instead of a big bundle. There are 32-bit and 64-bit libraries, under /opt/csw/gxx/lib and /opt/csw/gxx/lib/{sparcv9,amd64}. If anyone's interested in trying them, I'll be happy to get feedback. Maciej
participants (5)
-
Julien Nitard -
Maciej (Matchek) Bliziński -
Mathias Gaunard -
Oliver Kowalke -
Peter Dimov