- Boost - lists.boost.org

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

Why all prog-fail test are failing
by Gennadiy Rozental 30 Sep '04

30 Sep '04

I already asked this one. Did I miss an answer? Gennadiy.

3 3

RE: [boost] Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 30 Sep '04

30 Sep '04

Hi, Perhaps my fault - It wasn't that easy to just define YY_NO_UNISTD_H to make graph compile with vc7.1. The problem is that two non-ANSI C functions is called: b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; A little documentation search on Win32 gives: <io.h> int _isatty(int); <stdio.h> int _fileno(FILE*); As for how to solve these non-portable stuff with perhaps some BOOST defines, I think you all know better than I do. Kindest Regards, Christian -----Original Message----- From: Doug Gregor [mailto:dgregor@cs.indiana.edu] Sent: Wed 2004-09-29 17:45 To: boost(a)lists.boost.org Cc: Subject: Re: [boost] Re: Graph broken for vc7.1 after 1.31? On Sep 29, 2004, at 9:25 AM, Vladimir Prus wrote: >> Were you able to check it on VC 7.1? > > No. I'd appreciate if you could try there. I'll try to do so later. > >>>> We'll deprecate it in 1.32.0 (when, hopefully, we will >>>> have a new GraphViz parser that works well) and remove it >>>> afterwards. >>> >>> How the new parser will be implemented? >> >> Spirit. > > Is it written yet? Would be interesting to see. I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in. >> Granted, they've dropped support for older, broken compilers, >> so someone will still be getting hurt by this. > > Right. OTOH, I start to wonder if BGL should drop support for old > compilers > as well. (borland and vc6 are marked unusable already). There seem to > be a > lot of workaround inside BGL which means even reading the code hard. We promised to keep the parts of the BGL needed for the Python lib in working order. But I've marked borland and vc6 unusable because they've never really been usable and are a huge maintenance burden. Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0