- Boost - lists.boost.org

Cross-compiling: linux host, qnx target. Perhaps it's a bug?
by Félix Robles 23 Sep '11

23 Sep '11

Hi, I've got KUbuntu 64bits installed: Linux findeton-PC 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I want to compile boost using qcc toolset (qcc versión 4.4.2) for a qnx target-os from a linux host, and I'm unable to compile python,serialization and test libs (the rest of them are fine). This is how I do it: $ ./bootstrap.sh And it goes fine, it uses the gcc compiler, not qcc, because I want to execute b2 in my linux machine. Then I use the following command: $ ./b2 --build-dir=/home/findeton/boost_1_47_0/ toolset=qcc target-os=qnx --build-type=complete -a And this is the kind of output I get: qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/tuple.hpp:10, from ./boost/python/numeric.hpp:10, from libs/python/src/numeric.cpp:6: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o" "libs/python/src/numeric.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/list.hpp:10, from libs/python/src/list.cpp:5: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o" "libs/python/src/list.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o... [ And after some of those, then I get some of this kind : ] qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/iserializer.hpp:47, from ./boost/archive/detail/interface_iarchive.hpp:22, from ./boost/archive/detail/common_iarchive.hpp:23, from ./boost/archive/basic_binary_iarchive.hpp:31, from ./boost/archive/binary_iarchive_impl.hpp:22, from ./boost/archive/binary_iarchive.hpp:20, from libs/serialization/src/binary_iarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -O3 -Wc,-finline-functions -Wc,-Wno-inline -shared -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o" "libs/serialization/src/binary_iarchive.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_oarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/oserializer.hpp:38, from ./boost/archive/detail/interface_oarchive.hpp:23, from ./boost/archive/detail/common_oarchive.hpp:22, from ./boost/archive/basic_binary_oarchive.hpp:34, from ./boost/archive/binary_oarchive_impl.hpp:23, from ./boost/archive/binary_oarchive.hpp:21, from libs/serialization/src/binary_oarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared

1 0

FW: Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

Thanks Steven. I now see the problem arises from using si::dimensionless with nautical::length (The error message I get depends on the included header files but is related to the operator+ (when absolute.hpp is included) or the lack of a specialized add_typeof_helper in case that for example si/area.hpp is included). I guess my misconception was that I silently assumed that the 'dimensionless' type was acting as a normal double, reinforced by the fact that the line with the pure multiplication (nm1 = d*nm2;) does compile OK. The documentation says that " Because dimensionless quantities have no associated units, they behave as normal scalars, and allow implicit conversion to and from the underlying value type or types that are convertible to/from that value type". I intended to use my TDimless type as a 'generic' type for dimensionless quantities, but I now understand these quantities still need to be related to a 'system' and every system would need its own dimensionless type, even though there is no relation to the base units that define the system. Would I need to explicitly define conversions (e.g. BOOST_UNITS_DEFINE_CONVERSION_FACTOR(nautical::dimensionless, si::dimensionless, double, 1.0); or is there a more elegant way to use dimensionless quantities across systems? Thanks again, Pieter -----Original Message----- From: Steven Watanabe [mailto:watanabesj@gmail.com] Sent: Friday, September 23, 2011 17:06 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Units problem with user-defined units and dimensionless quantities AMDG On 09/21/2011 12:29 PM, Pieter wrote: > I am having some trouble using user-defined units and dimensionless once. > Consider the example (taken straight from the documentation) that > defines nautical miles (added at the bottom). > > When I do the following on VS2010: > > typedef quantity<boost::units::nautical::length> TDistanceInNMI; > typedef quantity<dimensionless> TDimLess; > > TDistanceInNMI nm1,nm2,nm3; > TDimLess d; > > nm1 = nm2 + nm3; // compiles OK > nm1 = d*nm2; // compiles OK > nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ > defined > > I suppose I might have to add a dimensionless type to the 'nautical' > system, or have some misconceptions on how this should work. I tried > adding the following line (mimicking some of the internal stuff) but > that did not due to trick: > > typedef unit<dimensionless_type,system> dimensionless; > I'm surprised that this doesn't work. It seems to work when I try it. The attached compiles with MSVC 2010. > Could anyone tell me whether there is there anything I need to define > to make this work? > In Christ, Steven Watanabe

1 0

Re: [boost] More tests running with Boost.Test than registered
by Jon Black 23 Sep '11

23 Sep '11

On 23-9-2011 7:42, boost-request(a)lists.boost.org wrote: >> So I put a print statement in the test in each DLL and ran it again, and > You could have used --log_level=all to see what is being tested Thanks. That's much nicer. >> > The project for MyDll1 depends on the other projects. That can't be a >> > coincidence! I'm confused though, why is the console_test_runner >> > executing tests in other DLL's when I've only specified MyDll1 on the >> > command line? Each DLL has its own unit_test_init() function declared in > You probably are using automatically registered test units. These are registered > in single shared test framework as soon as you load these libraries and they are > loaded in memory as they are dependencies of the library you want to test. Thus > you end up with all test units in all loaded libraries. Yes, they are automatically registered tests. In the init_unit_test() method I also give the master test suite a unique name for each DLL. If there is on shared test framework, does this mean I'm just renaming the same master test suite each time? > You can specify the test case belonging to the Mydll1 using --run=TestMyDll1 and > you'll get only 1 test case being executed. Perfect! I've used run_test to limit to a test suite which I've auto registered per project. > I think this is correct behavior overall. What you got here is implicit > dependency between test units you can't be sure TestMyDll1 working until you > tested all of it's dependent test cases which are in this case reside in > corresponding libraries. Agreed. I'm running it as a post build step. Adding the run_test option to limit what is executed solves my problem. Thanks. > Gennadiy

2 1

Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

LS, I am having some trouble using user-defined units and dimensionless once. Consider the example (taken straight from the documentation) that defines nautical miles (added at the bottom). When I do the following on VS2010: typedef quantity<boost::units::nautical::length> TDistanceInNMI; typedef quantity<dimensionless> TDimLess; TDistanceInNMI nm1,nm2,nm3; TDimLess d; nm1 = nm2 + nm3; // compiles OK nm1 = d*nm2; // compiles OK nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ defined I suppose I might have to add a dimensionless type to the 'nautical' system, or have some misconceptions on how this should work. I tried adding the following line (mimicking some of the internal stuff) but that did not due to trick: typedef unit<dimensionless_type,system> dimensionless; Could anyone tell me whether there is there anything I need to define to make this work? Any help is appreciated, Many thanks, Pieter --- The example --- namespace boost { namespace units { namespace nautical { struct length_base_unit : base_unit<length_base_unit, length_dimension, 1000> { static std::string name() { return "nautical mile"; } static std::string symbol() { return "nmi"; } }; typedef make_system<length_base_unit>::type system; typedef unit<length_dimension,system> length; // 'typedef unit<dimensionless_type,system> dimensionless'; static const length mile,miles; } } } // helper for conversions between nautical length and si length BOOST_UNITS_DEFINE_CONVERSION_FACTOR(boost::units::nautical::length_base_uni t, boost::units::si::meter_base_unit, double, 1.852e3); Pieter

2 1

Re: [boost] [contract] extra type requirements for contracts
by Brent Spillner 23 Sep '11

23 Sep '11

On Thu, 22 Sep 2011 08:03:09 lcaminiti wrote: >For example, the following code asserts back() == value only when >can_call_equal<T>::value is true. However, is there a better way to do this >that does not require the extra function call to post1? Unless I'm missing something, you should be able to replace the post1() calls with assert(boost::can_call_equal<T>::value && std::clog << "actual assertion\n" == std::clog && back() == value || std::clog << "trivial assertion\n" == std::clog);

3 5

structured exceptions for UNIXs -- the hard way
by Peter Foelsche 23 Sep '11

23 Sep '11

On UNIXs one does not get around signals. They are used for everything. E.g. using memory mapped io is impossible without dealing with signals. E.g. somebody may edit the file which is mapped into your process thereby truncating it and invalidating some part of the memory. Or one may be writing into a sparse file via memory mapped io and the result of "out of disk space" is also a signal. Then there are such sick solutions as setjmp()/longjmp(). Could they be packed into some class to enable some kind of structured exceptions on UNIXs? #include <setjmp.h> #include <vector> static std::vector<jmp_buf> s_sStack; static void signalHandler(void) { if (s_sStack.size()) { jmp_buf s = s_sStack.back(); s_sStack.pop_back(); longjmp(s); } } struct CSetLongJmp { CSetLongJmp(void) { s_sStack.push_back(jmp_buf()); if (setjmp(s_sStack.back())) throw "something"; } ~CSetLongJmp(void) { s_sStack.pop_back(); } }; This class would need to be part of anything which needs to be protected against signals: std::string s; CSetLongJmp s1; useString(s); Peter Foelsche

9 12

Re: [boost] Bugs in regression/library_status.cpp on Windows
by Robert Kawulak 22 Sep '11

22 Sep '11

Hi, Since there was no response to my emails with patches for two months now and the code is still broken as it was, should the tool be considered abandoned? If so, would it be acceptable if I apply the patches by myself? Best regards, Robert > -----Original Message----- > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > Sent: Monday, July 25, 2011 12:18 AM > To: 'boost(a)lists.boost.org' > Subject: RE: Bugs in regression/library_status.cpp on Windows > > Hi, > > Could anybody please apply that patch or suggest what can I do (or whom > to contact directly) to get this fixed? BTW, I wonder how it's possible > that most of the bugs were introduced in one commit half a year ago and > nobody even noticed - it would suffice to run this app on any platform > to get obvious errors while on Windows it wouldn't even compile. Am I > really the only person using this tool? :P > > I've also found another minor problems: > - when building it, "$(BOOST_ROOT)\tools\regression\build\bin" > directory is created but it's not marked with "ignore" in SVN; > - char_xlate functor only translates '/' character in URLs while on > Windows the character used is '\' (and it also causes problems in some > browsers). The solution is very simple - add "|| c = '\\'" in line 75. > > I'm attaching a patch file combining the previous fixes and the '\' > translation. > > Best regards, > Robert > > > > > -----Original Message----- > > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > > Sent: Saturday, July 09, 2011 11:35 PM > > To: 'boost(a)lists.boost.org' > > Cc: 'bdawes(a)acm.org'; 'blelbach(a)cct.lsu.edu' > > Subject: Bugs in regression/library_status.cpp on Windows > > > > Hello, > > > > I've stumbled upon several bugs in > > tools/regression/src/library_status.cpp when compiling on Windows > with > > gcc 4.5 and msvc 10.0. I'm attaching a patch file with all necessary > > fixes. The bugs are: > > > > - using path::native() instead of path::string() - the former is > > wstring on Windows, > > - calling path::string() twice to obtain begin() and end() iterators > - > > on Windows path::string() returns a temporary, so the iterators point > > to different objects, > > - using whole path for each node in build_node_tree() instead of only > > the directory name, > > - using whole path instead of only the test name in do_table_body(), > > - the link to links file is relative to test directory, not to the > > results output directory, > > - generation of closing "</a>" without opening "<a>". > > > > Best regards, > > Robert

1 0

More tests running with Boost.Test than registered
by Jon Black 22 Sep '11

22 Sep '11

I have a large solution in Visual Studio (100+) projects, of which most are dll's. The test code is in the DLL's and the tests are run using the provided console_test_runner. At the moment, each DLL has a single passing test. However, when I run the console_test_runner on a single dll, the output indicates that there are more tests. For example: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... *** No errors detected So I put a print statement in the test in each DLL and ran it again, and here's what happened: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... TestMyDll5 TestMyDll4 TestMyDll3 TestMyDll2 TestMyDll1 *** No errors detected The project for MyDll1 depends on the other projects. That can't be a coincidence! I'm confused though, why is the console_test_runner executing tests in other DLL's when I've only specified MyDll1 on the command line? Each DLL has its own unit_test_init() function declared in the pre-compiled header, so I'm really lost on what is happening here. Is it possible that the other dll tests are getting registered as well?

2 1

preprocessor programming challenge
by Eric Niebler 22 Sep '11

22 Sep '11

I have a PP interface such as the following: #define MACRO(x) \ typedef x type; \ typedef x::nested nested; struct D { struct nested {}; }; It is intended to be used as follows: struct foo { MACRO(D) }; Now the problem comes when x is a dependent type, because "typedef x::nested" needs a "typename" in there. I would like to additionally support the following syntax (or something like it): template<class DD> struct bar { MACRO(typename DD) }; The above doesn't work as is because "typedef typename DD type;" is ill-formed (although msvc eats it). Constraints are i/ the interface must be backwards compatible to avoid breaking existing clients, ii/ it should be done with PP only. No templates should be instantiated here, and iii/ it should be standard C++03. No PP variadics. Is this possible? I think not, but my PP-foo is weak. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Name and Namespace for Potential Boost Extended Floating-Point
by Christopher Kormanyos 22 Sep '11

22 Sep '11

Hello, We are seeking a good name for a potential boost extended precision floating-point library. This is a multiple precision floating-point type which *behaves* well in C++. The original thread announcing this potential library is here: http://lists.boost.org/Archives/boost/2011/06/182334.php Some very helpful boosters are assisting me with the preparation of this potential library. We've still got a lot to do, but are making good progress. In order to continue, we need a good name for a potential boost multiple-precision floating-point type. For the multiple-precision real type we have names like: * multiprecision_real * mp_real * extended_float_tOur current favorite is the second:mp_real. For namespaces, we have: 1. boost::mp::mp_real 2. boost::multiprecision::mp_real 3. boost::multiple_precision::mp_realOur current favorite namespace is number 2: boost::multiprecision. This new data type behaves like a drop-in replacement for a POD. It also has a collection of transcendental functions and a complex data type. So we are proposing: namespace boost { namespace multiprecision { class mp_real { ... }; // The real data type. class mp_complex { ... }; // The complex data type. mp_real sin(const mp_real&); // The sin function for the real data type. class mp_uint { }; // A potential future multiple-precision unsigned integer type. class mp_int { }; // A potential future multiple-precision signed integer type. } } We would appreciate comments (negative or positive) and/or alternative suggestions for names. Thank you. Sincerely, Chris.

15 56