- Boost-users - lists.boost.org

uBlas and random installation problem!
by Stefan Koch 22 Dec '05

22 Dec '05

----- Weitergeleitete Nachricht von stefan.koch(a)s2000.tu-chemnitz.de ----- Datum: Fri, 16 Dec 2005 14:58:16 +0100 Von: Stefan Koch <stefan.koch(a)s2000.tu-chemnitz.de> Antwort an: Stefan Koch <stefan.koch(a)s2000.tu-chemnitz.de> Betreff: [Boost-users] uBlas and random installation problem! An: boost-users(a)lists.boost.org Hello, I have a problem with the installation proberties for Library. I want use "--with-<library>", but i don't know how. --with-random --with-uBlas Are that the right Command? This is my gcc command row: /boost_1_33_1/tools/build/jam_src/bin.linuxx86/bjam -sTOOLS=gcc --prefix=/boost_1_33_1/MBoost --exec-prefix=/boost_1_33_1/MBoostLib --builddir=MBuild --with-random --with-uBlas --without-python install --> compiler make directory and fileclones for include for example: FileClone /boost_1_33_1/MBoost/include/boost-1_33_1/boost/algorithm/string/formatter.hpp not more!! No installation is done! Thanks for answer Cook ----- Ende der weitergeleiteten Nachricht -----

2 1

bjam using vc7.1
by Scott Harris 21 Dec '05

21 Dec '05

Hi, I have used a few boost libraries that did not require me to use bjam (just templates) but now I am trying to use bjam to build some examples in boost. I have an environment like: set BOOST_ROOT=C:\scott\boost\boost_1_33_1 REM because asio documentation said it needed to be defined set BOOST_DATE_TIME_NO_LIB=value_does_not_matter REM trying to avoid this warning REM Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately REM Assuming _WIN32_WINNT=0x0500 (i.e. Windows 2000 target) REM windows XP = 0x0501 set _WIN32_WINNT=0x0501 REM Boost Build requirements set VC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 set PATH=%VC71_ROOT%\bin;C:\scott\boost\bin;%PATH% vcvars32.bat Some questions: 1) How do I avoid the following warning output when building with bjam? Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately Assuming _WIN32_WINNT=0x0500 (i.e. Windows 2000 target) 2) I am used to having solution and project files for Microsoft Development Environment (MDE) using Visual C++. bjam apparently does not create these files. Can I get bjam to create project files? How does one use the debugger in MDE without project files? It would be inconvenient to have to always attached to a running process. Thanks, Scott

2 1

Problems installing uBLAS using HP-UX/G++
by David M Garza 21 Dec '05

21 Dec '05

I would like to install parts of Boost, for now the uBLAS and smart pointer libraries, on a workstation running HP-UX 11.22. I'm using gcc 3.4.3, not HP's C++ compiler. bjam seems to build okay, but when I try to use bjam to install just the uBLAS library using the command ~/bin/bjam "-sTOOLS=gcc" --prefix=/home/dgarza/ --builddir=/tmp/build-scratch/ --with-ublas it tries to build Boost.Python, Boost.Regex, and possibly other libraries, then gives the message ...found 3330 targets... then quits saying nothing else. I know it's trying to build Python and Regex because it prints messages about building those libraries, I don't know what else it's trying to build. When I add "stage" to the end of the command, bjam tries to build Python and Regex, then says don't know how to make stage ...found 1 target... ...can't find 1 target... When I try "install" instead of "stage," bjam seems to try installing everything. It ends with the message ...updated 3571 targets... The bjam documentation and help say the --with- option should make bjam just build/stage/install the specified library, but that isn't what is happening. Is there a list of dependencies for the different parts of Boost? Does uBLAS actually require Python and Regex? Related to this, would it be possible to provide a list of the names acceptable in the --with- and --without- options? Since uBLAS is under numeric I wasn't sure if the appropriate library name was numeric, ublas, uBLAS, numeric/ublas, etc. I tried to see if I could find a list of names somewhere but I nothing jumped out in the files I looked at. Does it just go by directory names? Thanks, David

6 26

Re: [Boost-users] Serialization library difficulties moving from 1.32 to 1.33
by Andrew Lin 21 Dec '05

21 Dec '05

> Damn - its a blunder alright - though it isn't yours. I see the problem. > Now I have to go back and fiigure out what I was doing when I introduced > it. In the meantime, changing save to save_override might do the trick. > > Robert Ramey Ah, okay. In the meantime it's no problem for me to stick with 1.32. Thanks for your help. ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ==============================================================================================

1 0

program_options error in 1.33.1
by Tino S. 21 Dec '05

21 Dec '05

Hi boosters, i have switch my code from 1.33 to boost 1.33.1 and the program_options is not working anymore. The first program in the example folder have the same error on my maschine. Here my work: System: Suse Linux with 2.6.5-7.111.5-default #1 Wed Nov 17 11:08:17 UTC 2004 i686 athlon i386 GNU/Linux >g++ -o first first.o -L/usr/lib/ -lboost_program_options-gcc gdb backtrace output: Reading symbols from /usr/local/lib/libboost_program_options-gcc-1_33_1.so.1.33.1...done. Loaded symbols for /usr/local/lib/libboost_program_options-gcc-1_33_1.so.1.33.1 Reading symbols from /usr/lib/libstdc++.so.5...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400f889d in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_stri ng () from /usr/lib/libstdc++.so.5 (gdb) backtrace #0 0x400f889d in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_stri ng () from /usr/lib/libstdc++.so.5 #1 0x080503f7 in _Construct<boost::program_options::option, boost::program_options::basic_option<ch ar> > (__p=0x8057198, __value=@0x80573b8) at stl_construct.h:78 #2 0x0805059e in std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<boost::program_options: :basic_option<char> const*, std::vector<boost::program_options::basic_option<char>, std::allocator<b oost::program_options::basic_option<char> > > >, boost::program_options::basic_option<char>*> ( __first=Variable "__first" is not available. ) at stl_iterator.h:602 #3 0x08050abd in std::vector<boost::program_options::basic_option<char>, std::allocator<boost::prog ram_options::basic_option<char> > >::operator= (this=0xbfffed70, __x=@0xbfffed50) at stl_uninitialized.h:109 #4 0x08052b7f in boost::program_options::basic_command_line_parser<char>::run (this=0xfffffff4) at parsers.hpp:84 #5 0x08053c9a in boost::program_options::parse_command_line<char> (argc=0, argv=0x0, desc=@0x0, style=-12, ext= {<boost::function_base> = {manager = 0, functor = {obj_ptr = 0x0, const_obj_ptr = 0x0, func_pt r = 0, data = ""}}, static args = <optimized out>, static arity = <optimized out>, invoker = 0}) at function_base.hpp:407 #6 0x0804c95e in main (ac=0, av=0x0) at function_template.hpp:278 Whats wrong with the parse_command funktion? Thanks in advance, Tino ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

1 0

Re: [Boost-users] compilation problems with the boost graph library and dijkstra_shortest_paths
by matthieu.ferrant＠agfa.com 21 Dec '05

21 Dec '05

1 0

Serialization library difficulties moving from 1.32 to 1.33
by Andrew Lin 21 Dec '05

21 Dec '05

Hello all, This is my first message so please forgive me if I've got the wrong list or a like blunder. I have a project using the Boost Serialization library with a custom archive. It works fine under Boost 1.32, but fails to compile under 1.33. A condensed test case: /////////////////////// #include <iostream> #include <boost/archive/detail/common_oarchive.hpp> class TestOArchive: public boost::archive::detail::common_oarchive<TestOArchive> { private: friend class boost::archive::save_access; public: void save_binary(void *address, size_t count); private: void save(int i) {std::cout << "got an int: " << i << '\n';} void save(const char* p) {std::cout << "got a char*: " << p << '\n';} }; int main() { TestOArchive ar; ar << 3; return 0; } /////////////////////// The test case is lifted almost directly from the documentation; it compiles and runs fine under 1.32 but does not compile under 1.33 (g++ 3.4.4 on Linux). The first of several error messages: /usr/local/include/boost-1_33/boost/archive/detail/interface_oarchive.hp p: In member function `const boost::archive::detail::basic_pointer_oserializer* boost::archive::detail::interface_oarchive<Archive>::register_type(const T*)': /usr/local/include/boost-1_33/boost/archive/detail/interface_oarchive.hp p:66: error: invalid use of undefined type `const struct boost::archive::detail::basic_pointer_oserializer' /usr/local/include/boost-1_33/boost/archive/detail/basic_oarchive.hpp:43 : error: forward declaration of `const struct boost::archive::detail::basic_pointer_oserializer' Any advice would be greatly appreciated. Andrew ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ==============================================================================================

2 2

Re: [Boost-users] Graph problem -- solvable using the Boost graph library ?
by matthieu.ferrant＠agfa.com 20 Dec '05

20 Dec '05

2 1

[BGL python binding]
by Yu Huang 20 Dec '05

20 Dec '05

HI Doug, The python binding for BGL is great. I tested the version, 0.9 downloaded from http://www.osl.iu.edu/~dgregor/bgl-python/. Unfortunately, it broke. But the version from " svn co https://svn.osl.iu.edu/svn/projects/viz/bgl-python" works though lots of warnings. I compiled it against boost 1.33.1. So i suggest you update the tarball link. Due to the old system on our cluster, i have to use python 2.2. The 'enumerate' is not available in 2.2. So a snip like below is necessary to be added to graph/docstring.py. def enumerate(ls): ls_to_return = [] for i in range(len(ls)): ls_to_return.append((i,ls[i])) return ls_to_return Yu

2 1

compilation problems with the boost graph library and dijkstra_shortest_paths
by matthieu.ferrant＠agfa.com 20 Dec '05

20 Dec '05

2 1