- Boost - lists.boost.org

[guid] bjam help
by Marc Viala 06 Mar '06

06 Mar '06

Hi, I'm just trying to configure bjam to compile the boost.guid library of Andy Tompkins but I'm not able to link correctly with the boost.thread: The linking step failed with the error indicated hereafter -> unable to find libboost_thread* library. I've joined the "bjamfile" for further analyse. Any help will be welcome. Best regards, Marc Viala -------------------------------- C:\Dev\MViala\ADV\boost_1_33_1\libs\guid\build>..\..\..\..\bjam\bjam "--builddir=C:\BoostBuild\Boost_1_33_1" ...patience... ...found 1327 targets... ...updating 60 targets... <snip> vc-C++ ..\..\..\bin\boost\libs\guid\build\libboost_guid.lib\vc-7_1\release\thre ading-multi\guid.obj guid.cpp vc-Archive ..\..\..\bin\boost\libs\guid\build\libboost_guid.lib\vc-7_1\release\thre ading-multi\libboost_guid-vc71-mt-1_33_1.lib Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. "..\..\..\bin\boost\libs\guid\build\libboost_guid.lib\vc-7_1\release\thr eading-multi\guid.obj" FileClone C:\Dev\MViala\ADV\boost_1_33_1\stage\lib\libboost_guid-vc71-mt-1_33_1.li b vc-Link ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\debug\threading -multi\boost_guid-vc71-mt-gd-1_33_1.dll ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\debug\threading -multi\boost_guid-vc71-mt-gd-1_33_1.lib LINK : fatal error LNK1104: impossible d'ouvrir le fichier 'libboost_thread-vc71-mt-gd-1_33_1.lib' "link" /nologo /INCREMENTAL:NO /DEBUG /DLL /subsystem:console /out:"..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\debug\thr eading-multi\boost_guid-vc71-mt-gd-1_33_1.dll" /IMPLIB:"..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\debug multi" /LIBPATH:"C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib" "boost_date_time-vc71-mt-gd-1_33_1.lib" "boost_thread-vc71-mt-gd-1_33_1.lib" @"..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\debug\threadi ng-multi\boost_guid-vc71-mt-gd-1 ...failed vc-Link ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\debug\threading -multi\boost_guid-vc71-mt-gd-1_33_1.dll ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\debug\threading -multi\boost_guid-vc71-mt-gd-1_33_1.lib... ...skipped <@boost!libs!guid!build!stage!lib>boost_guid-vc71-mt-gd-1_33_1.dll for lack of <@boost!libs!guid!build\boost_guid.dll\vc-7_1\debug\threading-multi>boos t_guid-vc71-mt-gd-1_33_1.dll... ...skipped <@boost!libs!guid!build!stage!lib>boost_guid-vc71-mt-gd-1_33_1.lib for lack of <@boost!libs!guid!build\boost_guid.dll\vc-7_1\debug\threading-multi>boos t_guid-vc71-mt-gd-1_33_1.lib... vc-Link ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\release\threadi ng-multi\boost_guid-vc71-mt-1_33_1.dll ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\release\threadi ng-multi\boost_guid-vc71-mt-1_33_1.lib LINK : fatal error LNK1104: impossible d'ouvrir le fichier 'libboost_thread-vc71-mt-1_33_1.lib' "link" /nologo /INCREMENTAL:NO /DLL /subsystem:console /out:"..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\release\t hreading-multi\boost_guid-vc71-mt-1_33_1.dll" /IMPLIB:"..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\releas e\threa " /LIBPATH:"C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib" "boost_date_time-vc71-mt-1_33_1.lib" "boost_thread-vc71-mt-1_33_1.lib" @"..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\release\threa ding-multi\boost_guid-vc71-mt-1_33_1.CMD" ...failed vc-Link ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\release\threadi ng-multi\boost_guid-vc71-mt-1_33_1.dll ..\..\..\bin\boost\libs\guid\build\boost_guid.dll\vc-7_1\release\threadi ng-multi\boost_guid-vc71-mt-1_33_1.lib... ...skipped <@boost!libs!guid!build!stage!lib>boost_guid-vc71-mt-1_33_1.dll for lack of <@boost!libs!guid!build\boost_guid.dll\vc-7_1\release\threading-multi>bo ost_guid-vc71-mt-1_33_1.dll... ...skipped <@boost!libs!guid!build!stage!lib>boost_guid-vc71-mt-1_33_1.lib for lack of <@boost!libs!guid!build\boost_guid.dll\vc-7_1\release\threading-multi>bo ost_guid-vc71-mt-1_33_1.lib... ...failed updating 4 targets... ...skipped 4 targets... ...updated 52 targets...

3 2

[Boost-bugs] [ boost-Bugs-1444052 ] [boost::lambda] Compile error with libstdc++ debug mode
by SourceForge.net 06 Mar '06

06 Mar '06

Bugs item #1444052, was opened at 2006-03-06 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444052&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: zaufi (zaufi) Assigned to: Nobody/Anonymous (nobody) Summary: [boost::lambda] Compile error with libstdc++ debug mode Initial Comment: in file boost/lambda/detail/operator_return_type_traits.hpp: line 862: #if BOOST_WORKAROUND(__GNUC__, >= 3) && _GLIBCXX_DEBUG should be #if BOOST_WORKAROUND(__GNUC__, >= 3) && defined(_GLIBCXX_DEBUG) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1444052&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[math, Tru64, V2] compex_test failures
by Vladimir Prus 06 Mar '06

06 Mar '06

Markus, there's a failure of math/complex_test on Tru64: http://tinyurl.com/zu33q I can't make much of it, so I'd suspect that there's some "make floating point more accurate" option that's passed in V1, and not passed in V2. Unfortunately, CVS does not contain tru64cxx71-006 toolset, so I can't compare the command lines myself. Any change you'll run the test with V1 and V2 (with -a -n, to get just commnad lines), compare the compile command lines and tell me if there are any significant differences, or just send the command lines to me? Thanks in advance, Volodya

3 4

[type_traits] is_base_and_derived on Borland 5.8.1
by Daniel James 06 Mar '06

06 Mar '06

Hi, is_base_and_derived isn't working on Borland 5.8.1, as you can see if you compare the test results for 5.8.1 (http://tinyurl.com/nru5r) and 5.6.4 (http://tinyurl.com/mh4s9) The attached patch might fix it. Please, could someone with access to the compiler try it out? thanks, Daniel

4 4

Listener-Registry Pattern implementation
by Dean Michael C. Berris 05 Mar '06

05 Mar '06

Good day everyone, I have just uploaded a simple implementation to the vault of my proposed listener-registry pattern implementation. Let me explain how this is different from Boost.Signals: 1) It doesn't use MPL (yet) -- since because the pattern is quite simple, I have implemented it such that the listener class should be inherited, and a handle() method should be overridden by the specific listeners. This would change, once I start learning more about MPL -- which should make the implementation more flexible at compile time. 2) It maps inputs to processors, while Boost.Signals allows you to use a signal which maps to different slots (which are all called in turn, once the signal is invoked). The listener-registry pattern implementation defines a registry to which listeners register themselves -- the registry then does the routing of inputs to the listeners. Think event driven processing, where a listener listens for a specific event and is invoked only when the specific input is passed into the registry which it is registered to. 3) It currently only intends to receive a single input type, which should change as I learn more about the MPL and how to make it more extensible with regards to compile time specification. The file is up at the vault (listener.tar.gz) and unfortunately, I chose to use the CppUnit test framework, and the GNU Make build system -- I've tried it on Ubuntu Linux 5.10, and requires libcppunit to build the test case. Comments, suggestions, and pointers most appreciated. Thanks, and hope to hear from you guys soon. -- Dean Michael C. Berris Mobile +639287291459 URL http://mikhailberis.blogspot.com YMID: mikhailberis

2 2

[tuple] Explicit member template function instantiation
by Felipe Magno de Almeida 04 Mar '06

04 Mar '06

Hi, I'm having trouble expliciting instantiating the const get member-function of a tuple. I defined my tuple like this: typedef boost::tuple<std::string, std::string> parameter_tuple; And I'm trying to instantiate like this: template boost::tuples::access_traits<boost::tuples::element<0, parameter_tuple::inherited>::type>::const_type parameter_tuple::inherited::get<0>() const; But it gives me the following error in VC7.1. I cannot understand why it says it has the wrong return value... I've tried using std::string const& too but didnt worked... ..\..\..\include\mail\type_parameters.hpp(26) : error C2785: 'access_traits<element<N,boost::tuples::cons<HT,TT>>::type>::const_type boost::tuples::cons<HT,TT>::get(void) const' and 'boost::tuples::access_traits<T>::const_type boost::tuples::cons<HT,TT>::get(void) const' have different return types with [ HT=std::string, TT=boost::tuples::detail::map_tuple_to_cons<std::string,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] and [ T=boost::tuples::cons<std::string,boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type>::stored_head_type, HT=std::string, TT=boost::tuples::detail::map_tuple_to_cons<std::string,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] ..\..\..\libs\boost\boost\tuple\detail\tuple_basic.hpp(405) : see declaration of 'boost::tuples::cons<HT,TT>::get' with [ HT=std::string, TT=boost::tuples::detail::map_tuple_to_cons<std::string,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] ..\..\..\include\mail\type_parameters.hpp(26) : see declaration of 'boost::tuples::cons<HT,TT>::get' with [ HT=std::string, TT=boost::tuples::detail::map_tuple_to_cons<std::string,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] ..\..\..\include\mail\multipart.hpp(90) : see reference to class template instantiation 'mail::multipart_detail::storage_selector_helper<MemoryStorageT,AsyncStorageT>' being compiled ..\..\..\include\mail\memory_storage.hpp(34) : see reference to class template instantiation 'mail::memory_storage_traits<T>' being compiled ..\..\..\include\mail\type_parameters.hpp(26) : error C2888: 'boost::tuples::access_traits<T>::const_type boost::tuples::cons<HT,TT>::get(void) const' : symbol cannot be defined within namespace 'mail' with [ T=boost::tuples::cons<std::string,boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type>::stored_head_type, HT=std::string, TT=boost::tuples::detail::map_tuple_to_cons<std::string,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] ..\..\..\include\mail\type_parameters.hpp(26) : error C3190: 'boost::tuples::access_traits<T>::const_type boost::tuples::cons<HT,TT>::get(void) const' with the provided template arguments is not the explicit instantiation of any member function of '<Unknown>' with [ T=boost::tuples::cons<std::string,boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type>::stored_head_type, HT=std::string, TT=boost::tuples::detail::map_tuple_to_cons<std::string,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat" >nul cl /Zm800 -nologo -TP /Z7 /Od /Ob0 /W4 /WX /GR /MDd /Zc:forScope /Zc:wchar_t /Wp64 /GB /wd4675 /EHs /wd4100 /wd4127 /wd4311 /wd4312 /wd4510 /wd4511 /wd4512 /wd4610 @"..\..\..\bin\projects\mail\test\multipart_basic.test\msvc-7.1\debug\multipart_basic.obj.rsp" -c -Fo"..\..\..\bin\projects\mail\test\multipart_basic.test\msvc-7.1\debug\multipart_basic.obj" Any help would be appreciated Thanks in advance, -- Felipe Magno de Almeida

1 0

Re: [boost] [vc-8_0]/EH option
by Mateusz Łoskot 04 Mar '06

04 Mar '06

Gennadiy Rozental wrote: > > It was brought to my attention that msvc toolset (and all derivatives) > doesn't allow to specify /EHa option. The Unit Test Framework *have* to be > compiled with this option. It seems that older versions on Microsoft > compiler deduced the need in async exception by themselves. This is > definitely needs to be address before release. Hi, Is there a chance to get this problem fixed in CVS shortly? Or it requires serious amount of changes? In the meantime, is this safe to use UTF binary built with VC++ 8.0 project files? Best regards -- Mateusz Łoskot http://mateusz.loskot.net

2 2

Re: [boost] [multi_index] BOOST_MULTI_INDEX_CONST_MEM_FUN and membertemplate functions
by JOAQUIN LOPEZ MU?Z 04 Mar '06

04 Mar '06

Hello Felipe, ----- Mensaje original ----- De: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Fecha: Viernes, Marzo 3, 2006 11:22 pm Asunto: [boost] [multi_index] BOOST_MULTI_INDEX_CONST_MEM_FUN and membertemplate functions > Hi, > > BOOST_MULTI_INDEX_CONST_MEM_FUN is implemented ths way: > > #define BOOST_MULTI_INDEX_CONST_MEM_FUN(Class,Type,MemberFunName) \ > ::boost::multi_index::const_mem_fun<Class,Type,&Class::MemberFunName> > > But when I need to do something like this: > > typedef boost::tuple<std::string, std::string> tuple; > > BOOST_MULTI_INDEX_CONST_MEM_FUN(tuple, std::string const&, get<0>); > > It doesnt work because of the two closing brackets that results from > the macro expansion. > Couldnt be added a space after &Class::MemberFunName ? > Here it works ok adding the space. > Of course, count on this being committed asap. I've got a couple of questions, though: 1. Regardless of whether your compiler takes the expanded macro as containing a '>>' instead of two '>'s, it is my understanding that a *conformant* preprocessor shouldn't do this. Is this correct? (I'll add the blank, anyway.) 2. Do you say this particular use of const_mem_fun (macro problems aside) works for you? Which compiler and version of Boost (1.33.1,CVS) are you using? I'm a little surprised because accessing tuple::get with const_mem_fun is a very tricky issue, as discussed for instance in the following thread: http://lists.boost.org/boost-users/2005/12/16087.php Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[multi_index] BOOST_MULTI_INDEX_CONST_MEM_FUN and member template functions
by Felipe Magno de Almeida 03 Mar '06

03 Mar '06

Hi, BOOST_MULTI_INDEX_CONST_MEM_FUN is implemented ths way: #define BOOST_MULTI_INDEX_CONST_MEM_FUN(Class,Type,MemberFunName) \ ::boost::multi_index::const_mem_fun<Class,Type,&Class::MemberFunName> But when I need to do something like this: typedef boost::tuple<std::string, std::string> tuple; BOOST_MULTI_INDEX_CONST_MEM_FUN(tuple, std::string const&, get<0>); It doesnt work because of the two closing brackets that results from the macro expansion. Couldnt be added a space after &Class::MemberFunName ? Here it works ok adding the space. Thanks, -- Felipe Magno de Almeida

1 0

[test] Possible design flaw in execution_monitor::catch_signals
by Jim Douglas 03 Mar '06

03 Mar '06

A recent problem I encountered that caused the total failure of a regression test run has highlighted what I (and others) believe to be a design flaw in execution_monitor::catch_signals (in file execution_monitor.ipp). IIUC the purpose of the code in question is to intercept UNIX signals and convert them to exceptions which contain a diagnostic message indicating the signal type. For most signals this should work reliably. However, we suggest that this mechanism is prone to failure when attempting to deal with a SIGSEGV, as happened in my case. What I observed was a test process that had stalled by blocking against a mutex. Detailed analysis showed that the test failed with a memory segment violation resulting in a SIGSEGV. In brief, the primary execution failure corrupts the program heap. When the C++ exception is thrown at execution_monitor:462, the exception handling mechanism calls __cxa_allocate_exception which then calls std::malloc. But, because of the corrupted heap, this call blocks against the malloc mutex. This is the specific case with QNX, and other OSs will deal with this in different ways. The general point I would like to make is that after a memory segment violation, any process's memory will be in an undefined state and it is unreasonable to assume that it will be capable of continued execution as per the present design. I propose that there is no safe way to intercept a SIGSEGV and that it should be allowed to terminate the process without intervention. Comments please... Jim

3 4