- Boost - lists.boost.org

[Random] GCC 2.95.3 regressions
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Given that the code compiles with the latests versions of the compiler, the following (from http://tinyurl.com/58lll) is most likely to be a compiler bug, but since the test used to pass some time ago, I was wondering if anyone is interested in making it work again or simply commenting on it before I mark it green: /boost/head-regression/boost/boost/random/xor_combine.hpp: In method `uint32_t boost::random::xor_combine<boost::random::linear_feedback_shift<unsigned int,32,31,13,12,0>,0,boost::random::linear_feedback_shift<unsigned int,32,29,2,4,0>,0,0>::min() const': /boost/head-regression/boost/boost/random/xor_combine.hpp:74: instantiated from `boost::random::xor_combine<boost::random::xor_combine<boost::random::linear_feedback_shift<unsigned int,32,31,13,12,0>,0,boost::random::linear_feedback_shift<unsigned int,32,29,2,4,0>,0,0>,0,boost::random::linear_feedback_shift<unsigned int,32,28,3,17,0>,0,0>::min() const' /boost/head-regression/boost/libs/random/random_test.cpp:251: instantiated from `instantiate_urng<boost::taus88, unsigned int>(const basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> > &, const boost::taus88 &, const unsigned int &)' /boost/head-regression/boost/libs/random/random_test.cpp:377: instantiated from here ... Date: 2004-09-26 06:35 set -e "/usr/local/gcc-2.95.3/bin/g++wrap" --limit-memory=600 --limit-cpu=1800 -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -I"../bin/boost/libs/random/test" -I "/boost/head-regression/boost" -o "../bin/boost/libs/random/test/random_test.test/gcc-2.95.3-linux/debug/random_test.o" "/boost/head-regression/boost/libs/random/random_test.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "../bin/boost/libs/random/test/random_test.test/gcc-2.95.3-linux/debug/random_test.o" Anyone? -- Aleksey Gurtovoy MetaCommunications Engineering

1 1

[Lambda] GCC 3.4.1 failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Jaakko, Could you please take a look/comment on the following failure in "bind_tests_simple_f_refs" (from http://tinyurl.com/52xlg) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"C:\MinGW\Bronek\boost\results\bin\boost\status" -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\status\bind_tests_simple_f_refs.test\mingw-3.4.1\debug\bind_tests_simple_f_refs.obj" "C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp" C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp: In function `int test_main(int, char**)': C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp:69: error: call of overloaded `bind(int (&)())' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:48: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<1, boost::lambda::function_action<1, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(), boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(Result (&)()) [with Result = int] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:70: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<1, boost::lambda::function_action<1, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&) [with Arg1 = int ()()] C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp:70: error: call of overloaded `bind(int (&)(int), int)' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:188: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(Par1), const Arg2, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(Result (&)(Par1), const Arg2&) [with Result = int, Par1 = int, Arg2 = int] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:210: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, const Arg2, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&, const Arg2&) [with Arg1 = int ()(int), Arg2 = int] [...] ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Test failure with STLPort
by Robert Ramey 30 Sep '04

30 Sep '04

I've noticed that you are testing the serialization library with the toolset msvc-stlport. I've tested that here and got most of to pass - at least as well as standard msvc. I had to make some changes though and I believe that you will have to make similar ones if you want the test to pass. I had to invoke the following before running the tests. export STLPORT_PATH="c:/" export STLPORT_VERSION=4.5.3 export STLPORT_INCLUDE_DIRECTORY="c:/program files/Microsoft Visual Studio/vc98/include/stlport" my stlport install process created a special set of stlport header files in the msvc include directory. This is and altered version of the original ones. The original ones compiler ok but they have some switches set so that some inline code is not included and this makes the test builds fail at link time. The above variables communicate information to the msvc-stlport toolset on where to look for the stlport headers. Note that the documentation on msvc-stlport jam is somewhat out of date so that confuses this issue as well. Note that failures of other STLPort toolsets that depended upon vc6 may be related to this issue as well. Robert Ramey

2 3

Python/GCC 3.4.1/Linux failures
by Gottfried.Ganssauge＠HAUFE.DE 30 Sep '04

30 Sep '04

David Abrahams wrote: > Martin Wille <mw8329(a)yahoo.com.au> writes: > > > David Abrahams wrote: > >> Martin Wille writes: > >> > >>>Trying: assert abs(rewrap_value_complex_float(4+.2j) - > (4+.2j)) < .000001 > >>>Expecting: nothing > >>>Segmentation fault > >> Wild guess: This is an ODR violation. The Boost.Python library and > >> the test shared library were compiled with a different > definition of > >> std::complex. > > > > How could that have happened? > > Weird INCLUDE picked up from the environment? Sorry, after that I'm > fresh out of wild guesses ;-) > > GDB should be able to show you what's going wrong, though. > > > Note, this is not the intel compiler, > > so flags like "-cxxlib-gcc" shouldn't be a problem here. Could the > > build system use so different flags that the resulting libraries > > wouldn't be interoperable? (I know this can happen rather easily > > on other systems. However, I haven't seen that with gcc on Linux > > as long as you stick to the same compiler version). > > > > Python was compiled using gcc 3.3.4. Could this cause the problem? > > (I don't think so.) It probably can if python was linked using the C++-Compiler. Gcc-3.3 uses libstdc++.so.5 for it's standard library whereas gcc-3.4 uses libstdc++.so.6. Probably both are dynamically linked to your extension (ldd will reveal if that's the case). Cheers, Gottfried

1 0

[Filesystem] Intel 7.1/Linux failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6) Compiler output []: /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(122): error: the global scope has no "readdir64" if ( (dp = ::readdir( handle )) == 0 ) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(313): error: incomplete type is not allowed struct stat path_stat; ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(314): error: the global scope has no "stat64" if(::stat( ph.string().c_str(), &path_stat ) != 0) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(339): error: incomplete type is not allowed struct stat lcl_stat; ^ [...] ? Should I mark the library as unusable in this configuration? -- Aleksey Gurtovoy MetaCommunications Engineering

3 8

Any Intel on Linux Gurus (help wanted with toolset for 8.1)?
by John Maddock 30 Sep '04

30 Sep '04

Apparently from Intel 8.1 onwards, we can no longer link C++ programs with icc as the current intel-linux toolset does: icc is now Intel's equivalent to gcc and performs a C only link, we need to use icpc to link C++ programs (and ideally to compile them as well, although icc currently still recognises C++ source and internally calls icpc). So here's the big question - does anyone have access to Intel 6 and/or 7 on Linux and do these also have icpc? If they do, then this is a no-brainer change to the toolset, but if not then we're going to have to get creative :-| Thanks, John.

2 2

ublas problem
by Matthias Troyer 30 Sep '04

30 Sep '04

Hi, I encounted a strange assertion failure in ublas: Assertion failed in file /Users/troyer/src/boost/boost/numeric/ublas/matrix_sparse.hpp at line 2603: !preserve internal logic Can anyone shed light on this? Matthias

1 0

[config] bcc configuration fix
by Tobias Schwinger 30 Sep '04

30 Sep '04

Just tripped over this (maybe still "sleeping") bug: Neither Builder 5 nor the free 5.5.1 tool chain do support member function specializations: 27a28 > # define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS

2 2

Re: [boost] Re: MultiMethod/Visitor Interest
by Danil Shopyrin 30 Sep '04

30 Sep '04

Hi! I think about multimethods as about generalized version of virtual method. There are compile time virtual methods in C++, and it's ok. Everyone practically use compile time virtual methods. And, by my opinion, the generalized version of them also should be compile time. Maybe we speak about different things? Maybe there should be at least two versions of multimethods: 1) as a generalization of traditional virtual methods; 2) as a generalization of "fully runtime polymorphism". >> Which file are you talking about? I talk about *.h/*.cpp files that aren't located in mm subfolder.

3 2

[Numeric/Interval] Mingw-3.4.1 failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Could somebody please take a look at these (from http://tinyurl.com/477vr) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\libs\numeric\interval\test\integer.test\mingw-3.4.1\debug\integer.obj" "C:\MinGW\Bronek\boost\boost\libs/numeric/interval/test/integer.cpp" In file included from C:/MinGW/Bronek/boost/boost/boost/numeric/interval.hpp:20, from C:\MinGW\Bronek\boost\boost\libs/numeric/interval/test/integer.cpp:11: C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::asinh_down(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:42: error: `::asinh' has not been declared C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::asinh_up(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:42: error: `::asinh' has not been declared C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp: In member function `T boost::numeric::interval_lib::rounded_transc_exact<T, Rounding>::acosh_down(const T&)': C:/MinGW/Bronek/boost/boost/boost/numeric/interval/rounded_transc.hpp:43: error: `::acosh' has not been declared [...] ? -- Aleksey Gurtovoy MetaCommunications Engineering

6 28