Regex no longer builds with toolset=sun
Hello, The last version of Boost that successfully builds on Solaris x86 32-bit with the Sun compiler (toolset sun) was version 1.43. Are there any plans to fix this toolset going forward? Thank you, Will Mason
On Mon, Jun 06, 2011 at 10:54:27PM -0500, Will Mason wrote:
The last version of Boost that successfully builds on Solaris x86 32-bit with the Sun compiler (toolset sun) was version 1.43. Are there any plans to fix this toolset going forward?
Hello, fellow obscure compiler user. What errors does the build produce, and which standard library are you building against: the native one or stlport? The last time I touched anything related to SunStudio it was fixing Boost.Array (which had some trouble understanding the syntax of functions returning array references). As for the toolchain in general, I believe it's not a first-tier compiler, which tends to lead to that errors detected by test runners may be ignored for a decent while. People tend to test their code on machines that they have immediately available and rely on the test runners (and their somewhat unorthodox configurations) to give a decent image of how their code fares. A decent way to get it fixed is to file proper bug reports, preferably with fixes attached. If it's really broken, you might have to file bug reports with standalone test cases against your compiler vendor. -- Lars Viklund | zao@acc.umu.se
The last version of Boost that successfully builds on Solaris x86 32-bit with the Sun compiler (toolset sun) was version 1.43. Are there any plans to fix this toolset going forward?
Unfortunately I don't have that platform to test on... and since we don't have a regular test-runner testing that platform either (care to volunteer?) I'm afraid I wasn't aware it was broken. It does build for me on Linux with sun's compiler though. Can you please post the error messages? Thanks, John.
On Tue, Jun 07, 2011 at 09:17:18AM +0100, John Maddock wrote:
The last version of Boost that successfully builds on Solaris x86 32-bit with the Sun compiler (toolset sun) was version 1.43. Are there any plans to fix this toolset going forward?
Unfortunately I don't have that platform to test on... and since we don't have a regular test-runner testing that platform either (care to volunteer?) I'm afraid I wasn't aware it was broken. It does build for me on Linux with sun's compiler though.
Can you please post the error messages?
I attempted a build on our last remaining SPARC machine at the department, where 1.46.1's regex built flawlessly. Sadly the 5.10 compiler on another machine is misconfigured, so I could only test with this one. $ CC -V says - CC: Sun C++ 5.9 SunOS_sparc 2007/05/03 $ ./bjam --with-regex # uneventful build log follows: ---8<--- Building the Boost C++ Libraries. ...found 71 targets... ...updating 9 targets... common.mkdir bin.v2 common.mkdir bin.v2/libs common.mkdir bin.v2/libs/regex common.mkdir bin.v2/libs/regex/build common.mkdir bin.v2/libs/regex/build/sun common.mkdir bin.v2/libs/regex/build/sun/debug common.mkdir bin.v2/libs/regex/build/sun/debug/stdlib-sun-stlport sun.compile.c++ bin.v2/libs/regex/build/sun/debug/stdlib-sun-stlport/has_icu_test.o sun.link bin.v2/libs/regex/build/sun/debug/stdlib-sun-stlport/has_icu ...updated 9 targets... Performing configuration checks - has_icu builds : yes Component configuration: - date_time : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - math : not building - mpi : not building - program_options : not building - python : not building - random : not building - regex : building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - wave : not building ...patience... ...found 608 targets... ...updating 47 targets... common.mkdir stage common.mkdir stage/lib common.mkdir bin.v2/libs/regex/build/sun/release common.mkdir bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport common.mkdir bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/c_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/cpp_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/cregex.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/fileiter.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/icu.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/instances.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/posix_api.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/regex.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/regex_debug.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/regex_raw_buffer.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/regex_traits_defaults.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/static_mutex.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/w32_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/wc_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/wide_posix_api.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/winstances.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/usinstances.o sun.link.dll bin.v2/libs/regex/build/sun/release/stdlib-sun-stlport/threading-multi/libboost_regex.so.1.46.1 common.copy stage/lib/libboost_regex.so.1.46.1 ln-UNIX stage/lib/libboost_regex.so common.mkdir bin.v2/libs/regex/build/sun/release/link-static common.mkdir bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport common.mkdir bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/c_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/cpp_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/cregex.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/fileiter.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/icu.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/instances.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/posix_api.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/regex.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/regex_debug.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/regex_raw_buffer.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/regex_traits_defaults.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/static_mutex.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/w32_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/wc_regex_traits.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/wide_posix_api.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/winstances.o sun.compile.c++ bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/usinstances.o sun.archive bin.v2/libs/regex/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/libboost_regex.a common.copy stage/lib/libboost_regex.a ...updated 47 targets... The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /scratch/zao/boost_1_46_1 The following directory should be added to linker library paths: /scratch/zao/boost_1_46_1/stage/lib ---8<--- -- Lars Viklund | zao@acc.umu.se
Hello,
On Tue, Jun 7, 2011 at 3:17 AM, John Maddock
have a regular test-runner testing that platform either (care to volunteer?) I'm afraid I wasn't aware it was broken. It does build for me on Linux with sun's compiler though.
Thanks a lot for the quick reply. I've done builds of Boost 1.46.1 with
versions 5.10 and 5.11 of Sun's compiler. The relevant output is attached.
The failures are the same with both versions of the compiler. Just to recap,
this is a 32-bit x86 box running Solaris 10. The builds were done with the
following characteristics: static linking, multi-threading, release variant.
To summarize: Sun's compiler hates the file regex_primitives.hpp. (Come to
think of it, that's not even from the regex library, is it?) I apologize for
blaming the regex library. It appears that the graph library is the problem.
Thanks,
Will
sun.compile.c++
bin.v2/libs/graph/build/sun/release/address-model-32/link-static/stdlib-sun-stlport/threading-multi/read_graphviz_new.o
"./boost/proto/transform/arg.hpp", line 306: Error: Partial specialization
for boost::proto::_byval::result has identical arguments.
"./boost/xpressive/regex_primitives.hpp", line 78: Error: Unexpected type
name "boost::proto::_data" encountered.
"./boost/xpressive/regex_primitives.hpp", line 78: Error: Unexpected type
name "boost::proto::_value" encountered.
"./boost/xpressive/regex_primitives.hpp", line 78: Error: Too many arguments
in cast to boost::xpressive::detail::push_back.
"./boost/xpressive/regex_primitives.hpp", line 79: Error: Unexpected type
name "boost::proto::_data" encountered.
"./boost/xpressive/regex_primitives.hpp", line 79: Error: Too many arguments
in cast to boost::xpressive::detail::push_back.
"./boost/xpressive/regex_primitives.hpp", line 569: Error: type is not a
member of boost::tr1_result_ofboost::proto::default_generator.
"./boost/proto/detail/expr0.hpp", line 458: Warning: A class with a
reference member lacks a user-defined constructor, which can lead to errors.
"./boost/xpressive/regex_primitives.hpp", line 569: Where: While
specializing "boost::proto::exprns_::expr
Unfortunately I don't have that platform to test on... and since we don't
have a regular test-runner testing that platform either (care to volunteer?) I'm afraid I wasn't aware it was broken. It does build for me on Linux with sun's compiler though.
Thanks a lot for the quick reply. I've done builds of Boost 1.46.1 with versions 5.10 and 5.11 of Sun's compiler. The relevant output is attached. The failures are the same with both versions of the compiler. Just to recap, this is a 32-bit x86 box running Solaris 10. The builds were done with the following characteristics: static linking, multi-threading, release variant.
To summarize: Sun's compiler hates the file regex_primitives.hpp. (Come to think of it, that's not even from the regex library, is it?) I apologize for blaming the regex library. It appears that the graph library is the problem.
Correct, I suggest you file a bug report against xpressive as that seems to be the problem component - Boost.Regex though appears to be OK? HTH, John.
On 6/8/2011 1:46 AM, John Maddock wrote:
On 6/8/2011 12:54 AM, Will Mason wrote:
To summarize: Sun's compiler hates the file regex_primitives.hpp. (Come to think of it, that's not even from the regex library, is it?) I apologize for blaming the regex library. It appears that the graph library is the problem.
Correct, I suggest you file a bug report against xpressive as that seems to be the problem component <snip>
Please just use Boost.Regex. Don't use xpressive with the sun compiler, and don't bother filing a bug about it. The problem is with sun's compiler -- it is far too broken to handle xpressive. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Hello,
On Tue, Jun 7, 2011 at 10:08 PM, Eric Niebler
Correct, I suggest you file a bug report against xpressive as that seems
to be the problem component <snip>
Please just use Boost.Regex. Don't use xpressive with the sun compiler, and don't bother filing a bug about it. The problem is with sun's compiler -- it is far too broken to handle xpressive.
Yes, I'm sorry that I'm a newb at managing Boost issues like this. I found later that there had been a bug filed for this exact thing today, and that the bug had been closed as not-my-problem. The thing is that I'm not trying to use xpressive; graph is. I can't control what graph decides that it wants to do. The somewhat annoying thing about it is that without omitting graph from the build, it just fails. Fortunately, I have no interest in graph, so I just omitted it. It would be kind of nice from the perspective of the user if graph would realize that it was attempting the impossible and that graph would just automatically be eliminated from the build with an appropriate warning. That kind of internal understanding of what was being attempted would have saved me many wasted hours. But I'm aware that saving me wasted time is not a high priority for you guys. :) Thanks for the attention that you all have given to this problem, Will
On 08/06/2011 05:35, Will Mason wrote:
The thing is that I'm not trying to use xpressive; graph is. I can't control what graph decides that it wants to do.
The somewhat annoying thing about it is that without omitting graph from the build, it just fails. Fortunately, I have no interest in graph, so I just omitted it. It would be kind of nice from the perspective of the user if graph would realize that it was attempting the impossible and that graph would just automatically be eliminated from the build with an appropriate warning. That kind of internal understanding of what was being attempted would have saved me many wasted hours. But I'm aware that saving me wasted time is not a high priority for you guys. :)
If Boost had a proper modular build system with dependencies, then it would do just that. Some people are working on it.
The somewhat annoying thing about it is that without omitting graph from the build, it just fails. Fortunately, I have no interest in graph, so I just omitted it. It would be kind of nice from the perspective of the user if graph would realize that it was attempting the impossible and that graph would just automatically be eliminated from the build with an appropriate warning. That kind of internal understanding of what was being attempted would have saved me many wasted hours. But I'm aware that saving me wasted time is not a high priority for you guys. :)
If Boost had a proper modular build system with dependencies, then it would do just that.
Really? I don't see how it would make any difference in this case - the graph lib would still fail to compile as before. You could add a configure step - "is xpressive usable on this compiler?" - before attempting to build the graph lib, but of course we could do that right now with Boost.Build.... John.
On 6/8/2011 4:41 AM, Mathias Gaunard wrote:
On 08/06/2011 05:35, Will Mason wrote:
The thing is that I'm not trying to use xpressive; graph is. I can't control what graph decides that it wants to do.
The somewhat annoying thing about it is that without omitting graph from the build, it just fails. Fortunately, I have no interest in graph, so I just omitted it. It would be kind of nice from the perspective of the user if graph would realize that it was attempting the impossible and that graph would just automatically be eliminated from the build with an appropriate warning. That kind of internal understanding of what was being attempted would have saved me many wasted hours. But I'm aware that saving me wasted time is not a high priority for you guys. :)
If Boost had a proper modular build system with dependencies, then it would do just that.
Some people are working on it.
Mathias - You don't really mean that I'm sure. Boost.Build does this fine. The authors of libs would obviously need to add the logic for compatibility... no different than any other system you might put in place. Lets keep the silly build system trolling wars on IRC ok? (o; -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
participants (6)
-
Eric Niebler -
John Maddock -
Lars Viklund -
Mathias Gaunard -
Michael Caisse -
Will Mason