- Boost-users - lists.preview.boost.org

Problem with Boost 1.31.0 Regex for tru64cxx65
by Richard Hadsell 29 Apr '04

29 Apr '04

Having found out how to build Bjam, I have tried to build the libraries of Boost 1.31.0 for tru64cxx65. I'm only interested in Regex at the moment, so I won't bother you with the problems building other libraries. When the build gets to this point: tru64cxx65-C++-action bin/boost/libs/regex/build/libboost_regex.so/tru64cxx65/release/cregex.o it hangs. I have run into this situation with other large files, and my usual remedy is to decrease the optimization level. How can I do that? If I can't do it for just this file, I'm willing to reduce the optimization level for the entire library, or even for all libraries. (This is not a platform that I worry about performance; it's just there to support a few vestigial machines.) -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 2

Cannot build bjam for tru64cxx
by Richard Hadsell 29 Apr '04

29 Apr '04

I am trying to upgrade from Boost 1.30.0 to 1.31.0. I am unable to build bjam from the source in tools/build/jam_src: 67% build.sh tru64cxx ### ### Using 'tru64cxx' toolset. ### rm -rf bootstrap.tru64cxx mkdir bootstrap.tru64cxx cc -o bootstrap.tru64cxx/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c command.c: compile.c: [snip] modules/sequence.c: ./bootstrap.tru64cxx/jam0 -f build.jam --toolset=tru64cxx --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap.tru64cxx/jam0 -f build.jam --toolset=tru64cxx --toolset-root= don't know how to make ...found 1 target... ...can't find 1 target... -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 5

Re: [Boost-users] Re: Config question: BOOST_NO_INTRINSIC_WCHAR_T(Intel7.1)
by Aleksey Gurtovoy 29 Apr '04

29 Apr '04

Christopher D. Russell writes: > Some additional information pertaining to BOOST_NO_INTRINSIC_WCHAR_T using > the Intel C++ 7.1 compiler in my MSVC 6 SP6 environment: > > Using Boost v1.31.0 + STLport v5.0-125 + Intel C++ v7.1 (I updated to build > 20030910Z) inside of MSVC 6 SP6 with a fairly recent MS Platform SDK, I > simply could not get boost/config/compiler/intel.hpp to send me down the road > to glory. In short, if you are running Intel in MSVC6 compatibility-mode and you are not compiling through bjam, you have to define BOOST_NO_INTRINSIC_WCHAR_T yourself -- either through command line or in the user config. If you are using bjam, the Intel toolset (http://tinyurl.com/2codz) does that for you. > > Inside of config/compiler/intel.hpp, _WCHAR_T_DEFINED is defined resulting in > BOOST_NO_INTRINSIC_WCHAR_T not being set. Subsequently, this results in the > compile-time error: > > boost/type_traits/is_integral.hpp(38): error: class > "boost::is_integral<unsigned short>" has already been defined > > Per "Compiler errors with Intel 7.1 and type_traits" > (http://lists.boost.org/MailArchives/boost/msg53033.php) specifically John > Maddock's reply (http://lists.boost.org/MailArchives/boost/msg53121.php) I > short-circuited the logic in config/compiler/intel.hpp and explicitly defined > BOOST_NO_INTRINSIC_WCHAR_T in config/user.hpp. This seems to work acceptably > for this project. But I'm not at all comfortable with this solution because I > really don't understand what the fundamental issue is with all this wchar_t > stuff. > > Forgive my ignorance but if, with my current working config, if I declare a > wchar_t type in my code I will get a 16-bit UCS-2 character. Correct? Having > now poured over all postings related to this subject in the archive, I have > an inkling that the root of all this stems from the way the compiler handles > type aliasing? Yes, more or less. > That is, with BOOST_NO_INTRINSIC_WCHAR_T a defined a wchar_t is actually an > alias for an unsigned int More likely 'unsigned short', but otherwise yes. > whereas in the case > !defined(BOOST_NO_INTRINSIC_WCHAR_T), the compiler treats wchar_t as an > intrinsic type? Yes. Or, rather, to be precisely clear, BOOST_NO_INTRINSIC_WCHAR_T _indicates_ to the Boost code that on the particular compiler/configuration 'wchar_t' is simply an alias for some other built-in integral type. It doesn't change the compiler's behavior. > And from this we get these template specialization errors? Yep. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Boost won't build
by Charles Polisher 28 Apr '04

28 Apr '04

$ pwd /BUILD_TREES/boost $ bjam "-sTOOLS=gcc" /usr/bin/locate/allyourbase.jam: Not a directory /usr/bin/locate/boost-base.jam: Not a directory /BUILD_TREES/boost/tools/build/v1/bootstrap.jam:22: in boost-build rule load-jamfiles unknown in module /BUILD_TREES/boost/boost-build.jam:16: in module scope $ gcc -v <snip> gcc version 3.3 20030226 (prerelease) (SuSE Linux) I get the same result with both the latest release (1.31.0) on sourceforge and with the CVS version. Google, the FAQ and the list archives haven't yielded up a clue. I *must* be overlooking something obvious. Help!

2 3

RE: [Boost-users] Config question: BOOST_NO_INTRINSIC_WCHAR_T (Intel7.1)
by Ben Hutchings 28 Apr '04

28 Apr '04

Christopher D. Russell <cdr(a)encapsule.com> wrote: > I'm just getting around to upgrade to Boost 1_31_0 from Boost 1_30_0. > I'm attempting to use 1_31_0 out-of-the-box (w/no bjam) but am > confused about how to resolve problems related to native wchar_t > support (or lack thereof). <snip error messages> > ... tracked back into .../1_31_0/boost/type_traits/is_integral.hpp > > #ifndef BOOST_NO_INTRINSIC_WCHAR_T > BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) > #endif > > ... where BOOST_NO_INTRINSIC_WCHAR_T is defined in > ../1_31_0/boost/config/compiler/intel.hpp > > // See http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864 > #if BOOST_INTEL_CXX_VERSION < 700 > # define BOOST_NO_INTRINSIC_WCHAR_T > #else > // _WCHAR_T_DEFINED is the Win32 spelling > // _WCHAR_T is the Linux spelling > # if !defined(_WCHAR_T_DEFINED) && !defined(_WCHAR_T) > # define BOOST_NO_INTRINSIC_WCHAR_T > # endif > #endif <snip> Since Intel C++ on Windows is supposed to be compatible with Visual C++ I think this should be testing _NATIVE_WCHAR_T_DEFINED and not _WCHAR_T_DEFINED. VC++ defines the latter if wchar_t is an intrinsic type *or* a type alias but it defines the former only if wchar_t is an intrinsic type. I couldn't find any detailed documentation for Intel C++ online so I don't know if it is exactly compatible in this respect.

1 0

Any one used boost with RISCOS and GCC
by dahman madani 28 Apr '04

28 Apr '04

To the community; I was wondering if anyone has experience using the boost libraries with the RISCOS platform Thanks Dahman

1 0

Problem building archive libs for mipspro
by Richard Hadsell 28 Apr '04

28 Apr '04

I am trying to upgrade from Boost 1.30.0 to 1.31.0. My main interest is in the Regex library. I was pleased to build its libraries successfully for intel-linux, both .a and .so forms, using bjam. When trying to build the libraries for mipspro, it fails to build the .a forms, because it is trying to use ranlib. The bjam system is too unfamiliar to me to debug it, so I'm hoping somebody else can give me a remedy. (Note: I built bjam from the source in tools/build/jam_src, as described in the docs.) Here is the evidence: 69% bjam "-sTOOLS=mipspro" --stagedir=stage "-sBUILD=debug release <threading>single" stage [snip] mipspro-Archive-action bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a --- C++ prelinker: bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/c_regex_traits.o --- [snip] Ranlib bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a /bin/sh[2]: ranlib: not found ranlib bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a ...failed Ranlib bin/boost/libs/regex/build/libboost_regex.a/mipspro/debug/libboost_regex-mp-d-1_31.a... ...skipped <@boost!lib>libboost_regex-mp-d-1_31.a for lack of <@boost!libs!regex!build/libboost_regex.a/mipspro/debug>libboost_regex-mp-d-1_31.a... [snip] -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 4

[BGL] jweb.sty and biconnected_components.w
by Sven de Vries 25 Apr '04

25 Apr '04

Hi, tried to latex the file biconnected_components.w. But it requires a package jweb that I can not find on ctan. Where could I get that from? thanks! sven

2 1

tokenizer: exceptions not documented
by Keith MacDonald 25 Apr '04

25 Apr '04

I discovered the hard way that tokenizer (from CVS head) can throw escaped_list_error. It would help if that was documented. Keith MacDonald

1 0

Iterators
by Witz 24 Apr '04

24 Apr '04

just a quick question - which maybe should have been directed at the developers list but ... would it be possible in the iterator adaptors to have an operator== defined that takes the base iterator as the right hand side? it would certainly cut down on typing and also obviate the need to create an end iterator that is only used as an 'end of container' sentinel value if it was possible it would allow us to write, for example: copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), numbers + N, ostream_iterator<int>(cout, " ")); rather than: copy( make_filter_iterator<is_positive_number>(numbers, numbers + N), make_filter_iterator<is_positive_number>(numbers + N, numbers + N), ostream_iterator<int>(cout, " ")); of course i am aware that i might be missing something obvious ... ian whittley

3 5