- Boost-users - lists.boost.org

Building boost on AIX with GCC -- pthread problems
by Dan Katz 15 Apr '05

15 Apr '05

Hi - I'm trying to build boost on an AIX box using GCC, and am having pthread issues. In particular: ------------------------------------------------------------------------ $ uname -a AIX dev-app-a00 2 5 00089FFC4C00 unknown unknown AIX $ gcc -v Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.3/specs Configured with: ../gcc-3.3.3/configure --disable-nls Thread model: aix gcc version 3.3.3 $ bjam -v Boost.Jam Version 3.1.10. OS=AIX. [... elided copyright stuff ...] $ bjam [... elided PYTHON stuff here ...] ...found 7231 targets... ...updating 840 targets... gcc-C++-action bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_month.o In file included from /home/dkatz/dev/Engine/Agorai/Boost/boost/detail/lwm_pthreads.hpp:20, from /home/dkatz/dev/Engine/Agorai/Boost/boost/detail/lightweight_mutex.hpp:92, from /home/dkatz/dev/Engine/Agorai/Boost/boost/detail/shared_count.hpp:28, from /home/dkatz/dev/Engine/Agorai/Boost/boost/shared_ptr.hpp:26, from /home/dkatz/dev/Engine/Agorai/Boost/boost/date_time/gregorian/greg_month.hpp:14, from /home/dkatz/dev/Engine/Agorai/Boost/libs/date_time/src/gregorian/greg_month.cpp:14: /usr/include/pthread.h:554: error: `pthread_rwlock_t' was not declared in this scope /usr/include/pthread.h:554: error: parse error before `)' token [... lots more pthread problems of this sort ...] ^C...interrupted $ ------------------------------------------------------------------------ Should I be configuring the gcc build with some other thread model maybe? Any insight would be useful. I've been googling around a bit, but haven't found much for this particular issue... Thanks. Dan

3 2

How to install only subset of header files
by Marcel Loose 15 Apr '05

15 Apr '05

Hi, Last week I mailed a question about how to install only a few libraries, but I did'nt get any replies. Maybe I didn't clearly enough explain what I wanted to ask. So I'll try again. Is it possible to only install a subset of all boost *header files*? More specifically, only the header files that are needed when installing one or more libraries. For example, suppose I only want to use Boost Smart Pointers and Boost.Threads. I would like Bjam to only install the header files that are needed for those two libraries, not *all* Boost header files. I know that you can and should use the bjam option --with-<library>, but, AFAIK, this only works for the library, not for the header files. Any help would be appreciated. Kind regards, Marcel Loose.

3 2

swapping keys in multiindex
by David Gruener 15 Apr '05

15 Apr '05

Hello, how can one swap keys in an *ordered* index of a multi index container? Well, you cannot say something like: blah.modify_key(blah.find(foo1), _1 = foo2); // from now index contains one element fewer, since // keys must be uniq blah.modify_key(blah.find(foo2), _1 = foo1); I dind't found a way in the manual to swap directly. --David

3 3

Question About Thread-Safety of boost::bind Library
by john.davison＠americas.bnpparibas.com 15 Apr '05

15 Apr '05

When I see placeholder variables ("_1", "_2", etc.) in Boost.Bind, the first thing that comes to my mind is, what are the effects of this on reentrancy and thread-safety in the Boost.Bind library? What must one watch out for when attempting to use the Boost.Bind library in a multithreaded program? Is it possible to make effective use of the Boost.Bind library while ignoring the ("_1", "_2", etc.) placeholder variables? The "Proposal to Add an Enhanced Binder to the Library Technical Report" of 2003-02-28 doesn't address these concerns, so I'm asking them here. Thanks. This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.

2 1

better patch for auto_unit_test.hpp "enhancement"
by Oliver Schoenborn 15 Apr '05

15 Apr '05

This is the same as last (http://article.gmane.org/gmane.comp.lib.boost.user/10508) except that it fixes a problem that would prevent a multi-unit auto unit test to run (i.e. if one of the test files did NOT have a BOOST_AUTO_TEST_MAIN). $ diff -u boost_1_32_0/boost/test/auto_unit_test.hpp patches/boost-1_32/boost/test/auto_unit_test.hpp --- /home/oschoenborn/downloads/boost_1_32_0/boost/test/auto_unit_test.hpp Mon Jul 19 09:12:40 2004 +++ /c/Boost/include/boost-1_32/boost/test/auto_unit_test.hpp Thu Apr 7 16:16:19 2005 @@ -19,6 +19,17 @@ // Boost.Test #include <boost/test/unit_test.hpp> +#define BOOST_AUTO_TEST_SUITE_DEFAULT_NAME "Auto Unit Test" +#ifdef BOOST_AUTO_TEST_MAIN + #ifndef BOOST_AUTO_TEST_SUITE_NAME + #define BOOST_AUTO_TEST_SUITE_NAME suiteName(BOOST_AUTO_TEST_MAIN) + #endif +#else + #ifndef BOOST_AUTO_TEST_SUITE_NAME + #define BOOST_AUTO_TEST_SUITE_NAME BOOST_AUTO_TEST_SUITE_DEFAULT_NAME + #endif +#endif + // ************************************************************************** // // ************** auto_unit_test_registrar ************** // // ************************************************************************** // @@ -27,10 +38,17 @@ namespace unit_test { namespace ut_detail { +inline const char* +suiteName(const char* name = NULL) +{ + return name ? name : BOOST_AUTO_TEST_SUITE_DEFAULT_NAME; +} + inline boost::unit_test::test_suite* auto_unit_test_suite() { - static boost::unit_test::test_suite* inst = BOOST_TEST_SUITE( "Auto Unit Test" ); + static boost::unit_test::test_suite* inst + = BOOST_TEST_SUITE( BOOST_AUTO_TEST_SUITE_NAME ); return inst; }

2 1

building boost w/o debug libs
by Daniel Goller 15 Apr '05

15 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i can't locate it in the docs where it explains how not to build the debug libs, i found it where i could exlude certain libs, build oooonly some, or build not the threaded libs, if i missed it a kind nudge in the right direction would be appreciated, or if not in docs, a simple sample option to bjam would be highly appreciated thank you in advance for your efforts Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXcSmUpKYMelfdYERAibsAJ9Rh3nSBWCDPWI4xs28//8M0BxExACdEOo0 6k14l84CKaEeMwORIRdxvDM= =HHCY -----END PGP SIGNATURE-----

3 3

boost::shared_ptr and stl algorithms
by Bill Eidson 15 Apr '05

15 Apr '05

std::vector< boost::shared_ptr<T> > TVec; I want to write a function object to run std::for_each. to do somework against members of T and accumulate results in functor. My attempts have failed in VC7 with memory errors in my operator() method. struct fo { bool operator()( boost::shared_ptr<T>& t ) { return true; } }; Thanks in advance bille

5 9

RE: [Boost-users] Re: MultiIndexSet invariant test failure
by Manges, Ross G 14 Apr '05

14 Apr '05

Joaquin M Lopez Munoz wrote: > Two (main) possibilities: the shared_ptr is invalid or > my code has a bug. Could you test the pointer for validity before > making the insertion? > > m.check_invariant_(); > // check ptr before insertion > m.insert(ptr); OK, so I print out the members of the object that the shared_ptr encapsulates, and it appears that the shared_ptr object is OK before insertion. > If still the error is detected inside insert(), we can try to produce > some sort of poorman dump of the container: define > BOOST_MULTI_INDEX_INVARIANT_ASSERT to throw an exception on failure > and wrap the call to insert() as follows: OK, I tried to use the following code, and recompiled, but I don't catch the exception, and in turn I see rather unpredictable behavior before my program dies violently. Is my macro definition incorrect? //************* begin **************** struct invariant_exception { invariant_exception() {} }; #define BOOST_MULTI_INDEX_INVARIANT_ASSERT(expr) \ if(!(expr)){throw invariant_exception();} //************* end ***************** > try{ > m.insert(...); > } > catch(/* exception thrown by the assert */){ > // dump the contents of m > } > > Can you do that? Notice something weird in the dump? > Can you post the dump? I will post the dump if I can get it to create one. Thanks for your perseverance! --Ross

1 0

RE: Boost thread problem
by C. Michailidis 14 Apr '05

14 Apr '05

> It seems the usage of the vector cases problems with the multithreaded programs on the multiprocessor machines. > I have changed it to queue and the bug has been resolved. I cannot reproduce it now. Huh, that's interesting! I suppose it may no longer be a major issue for you then (even though vectors and queues have different algorithms under the hood). Because you mentioned that the problem seems to be limited to true SMP systems, I tried your code again (this time on a dual cpu system) and I still couldn't reproduce it. I must admit that the process didn't seem to bounce between cpus though, so perhaps something is lost in the shuffle in that regard. The dual cpu system was configured similarly to the first machine that I tried it on (FreeBSD 5.3 + boost 1.32.0_2). The first machine (although not a 'true' smp system) is using hyperthreading w/ an SMP kernel so as far as the OS is concerned it too is a multiprocessor machine. If you still want to isolate the problem that you *were* having (using vector) then you may be interested in the details of thread-safe CRTs. The "-lc_r" indicates that (on FreeBSD) the re-entrant C library (i.e. thread-safe) should be linked against. On Windows I believe the analog is called something like 'msvcrtmt.dll' (C RunTime - MultiThreaded). I would hope that the .NET compiler uses this 'msvcrtmt.dll' when 'multithreaded support is on', but I couldn't tell you for sure. If you're statically linking, I think the name is just 'msvcrtmt.lib'. The thread-unsafe version doesn't have 'mt' appended to the library filename. The glamour of MSFT development has been largely replaced with a desire to actually get stuff working so... most of my development has been on FreeBSD lately. Therefore some of this MSFT specific information may not be exactly correct. Oh how the cobwebs accumulate! Anyway, you could probably double check for the 'msvcrtmt' library by looking at the detailed linker settings, that is if my suspicion concerns you and you're still interested in isolating the problem. In any case, I'm glad you found a work-around! C. Michailidis Balston Research LLC

1 0

RE: [Boost-users] Re: MultiIndexSet invariant test failure
by Manges, Ross G 14 Apr '05

14 Apr '05

Joaquin M Lopez Munoz wrote: > You've got to implement semantics equivalent to that of > the < relationship between numbers: Thanks for the info; I now believe I'm doing this correctly. > * Now, in the piece of your code where the insert asserts, > add a precheck of the invariant: > > m.check_invariant_(); // point A > m.insert(...); // point B > > * Run your test till the assert fires. Is it in point > A or B? If A, then most likely you're somehow modifying > the elements in some other thread. Get the idea? This is a great idea! I added the precheck as you suggested, and it appears that I am experiencing the assert in 'point B'. The invariant is OK until the insertion breaks it. So can I infer that somehow what I'm inserting is invalid? It's a shared_ptr. I recently sent in another post regarding problems I'm having with shared_ptrs that might be related (see post w/subject: "shared_ptr use_count in multi threaded environment"). Thanks!

2 1