- Boost - lists.boost.org

Using Boost.Book
by Arkadiy Vertleyb 27 May '05

27 May '05

The discussion about Boost.Build is valuable by itself, but OTOH, (why) do I need the Boost.Build to use the Boost.Book? Isn't Boost.Build just a way to run something that otherwise can be run from the command line? Regards, Arkadiy

2 2

[serialization] Another patch for Tru64
by Markus Schöpflin 27 May '05

27 May '05

Attached patch fixes a test failure on Tru64. As it could possibly affect other users of the RW library, I'm asking if anyone has any objections to this patch. Markus Index: remove_whitespace.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/archive/iterators/remove_whitespace.hpp,v retrieving revision 1.6 diff -u -r1.6 remove_whitespace.hpp --- remove_whitespace.hpp 27 Jan 2005 17:34:53 -0000 1.6 +++ remove_whitespace.hpp 25 May 2005 11:43:20 -0000 @@ -47,7 +47,8 @@ #endif #if defined(__STD_RWCOMPILER_H__) || defined(_RWSTD_VER) -// this is required for the RW STL on Linux: +// this is required for the RW STL on Linux and Tru64. +#undef isspace #undef iswspace #endif

2 2

Bowjlvuzgnwsfcajk
by mark.rodgers＠cadenza.co.nz 27 May '05

27 May '05

1 0

Re: Building boost for 64-bit on AIX [shared_ptr & single threading]
by Rene Rivera 26 May '05

26 May '05

Patrik Jonsson wrote: > Rene Rivera wrote: > >> Well that's a single threaded library, it would have "threading-multi" >> in the path if it was multi threaded. >> >>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock >>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock >>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init >>> ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy >> >> >> >> It's likely that something other than Boost requires pthread. Could >> you find out what that is? It could be libstdc++, or something else.. >> > It seems to be that boost/greg_month.hpp includes boost/shared_ptr.hpp, > which uses boost/detail/shared_count.hpp which uses > /boost/detail/lightweight_mutex.hpp. The pthread symbols are in > greg_month.o, so it looks like that library won't work without threads > or else something's supposed to turn threads off but isn't working... Hmm... The only fix for this I can come up with is to add "<define>BOOST_LWM_USE_SPINLOCK", or probably more safely add "<linkflags>-pthread" to the BUILD. The current code, what's going to be 1.33, is rather different and is likely not to rely on pthreads on your platform. I think it uses native assembly in the GCC+PPC case. But more generally I would think that it should not generate *any* locking code when doing a single threaded build. I'm CC'ing the Boost list in the hope someone else can better resolve the problem. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 2

how to build the quickbook?
by Arkadiy Vertleyb 26 May '05

26 May '05

Hi all, I just checked out the Boost CVS repository, and want to build the quickbook. However I can't find Jamfile there -- there is only Jamfile.v2. How should I build it? Thanks in advance, Arkadiy

3 3

[function_traits] Functions and function objects?
by Rene Rivera 26 May '05

26 May '05

The docs for function_traits.. http://www.boost.org/libs/type_traits/index.html#function_traits Don't mention if the traits work just for function types. Or if they will also work with function objects. Does it? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

Upcoming lists.boost.org outage, FYI
by David Abrahams 26 May '05

26 May '05

-- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: Microsoft Pragma(lib) decls (was RE: [boost] Customer Friendlier Boost Installation)
by Victor A. Wagner Jr. 26 May '05

26 May '05

At 11:08 2005-05-26, Bennett, Patrick wrote: > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] > > On Behalf Of Victor A. Wagner Jr. [deleted] > > >in with users having no idea how or why they're being linked against. > > >Since many developers tend to be rather over-eager in #including >headers > > >(bah, just include it all!) > > > > sounds like "many developers" need to be re-edcuated. or, perhaps, >you > > need better code walkthroughs. > >[Bennett, Patrick] Both. :) That doesn't change the fact that having >object files which contain special decorations (inserted by a >vendor-specific #pragma operation) that's twice in 2 days that someone wants to pick on #pragma being "vendor specific" I never suggested either time a literal "#pragma blah" to support this. >which cause unspecified libraries to >'automatically' get linked in is a 'bad thing.' >For one, there's no official way to dump a list of these explicit link >references for any given object file or lib/dll. were the mechanism part of the standard, of course there would be an "official" way to find them >The only way to (partially) know what might get linked in ahead of time >is to go through a dedicated preprocessor step to verify what's being >linked. Of course, this just handles the case where the public >(interface) headers of all libraries referenced contain pragma/lib >entries. It doesn't account for the libraries which defined pragma/lib >entries for other libraries within their implementation headers [so the >pragma node is only in the linkable file for that static lib or dll's >import lib]. Thus, there's no way to 'know' up-front, and in an >easy/fast manner, what libraries will actually be linked in when >building a dll or exe in the presence of these lib pragma's. They're >bad, bad, bad. you assumed things I didn't suggest. >Vendors like Microsoft are certainly welcome to support them, but adding >something like this to the 'standard' would be unacceptable (to me at >least ;>). If tool authors want to provide support for Microsoft's >extension, that's fine too - it should just always be optional. > >When it comes to compiling and linking, I don't want the compiler or >linker including anything more than I explicitly told it to include. > >If you disagree, well, hey, I guess we'll just have to agree to >disagree. no, I'm gonna convince you, lol. >Cheers... >Patrick Bennett Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Microsoft Pragma(lib) decls (was RE: [boost] Customer Friendlier Boost Installation)
by Bennett, Patrick 26 May '05

26 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Victor A. Wagner Jr. > Sent: Wednesday, May 25, 2005 10:34 PM > To: boost(a)lists.boost.org > Subject: RE: [boost] Customer Friendlier Boost Installation > > At 14:30 2005-05-25, Bennett, Patrick wrote: > >[delete] > >[Bennett, Patrick] Personally, I think the pragma 'link' options are an > >absolute disaster for large projects. > > apparently you've worked with different folks than I. Likely, different > kinds of "large projects", too. [Bennett, Patrick] Well, a single full build is over 55 GB. To me at least, that's large. :) > >It's far, far too easy to end up with lots of libraries getting linked > >in with users having no idea how or why they're being linked against. > >Since many developers tend to be rather over-eager in #including headers > >(bah, just include it all!) > > sounds like "many developers" need to be re-edcuated. or, perhaps, you > need better code walkthroughs. [Bennett, Patrick] Both. :) That doesn't change the fact that having object files which contain special decorations (inserted by a vendor-specific #pragma operation) which cause unspecified libraries to 'automatically' get linked in is a 'bad thing.' For one, there's no official way to dump a list of these explicit link references for any given object file or lib/dll. The only way to (partially) know what might get linked in ahead of time is to go through a dedicated preprocessor step to verify what's being linked. Of course, this just handles the case where the public (interface) headers of all libraries referenced contain pragma/lib entries. It doesn't account for the libraries which defined pragma/lib entries for other libraries within their implementation headers [so the pragma node is only in the linkable file for that static lib or dll's import lib]. Thus, there's no way to 'know' up-front, and in an easy/fast manner, what libraries will actually be linked in when building a dll or exe in the presence of these lib pragma's. They're bad, bad, bad. Vendors like Microsoft are certainly welcome to support them, but adding something like this to the 'standard' would be unacceptable (to me at least ;>). If tool authors want to provide support for Microsoft's extension, that's fine too - it should just always be optional. When it comes to compiling and linking, I don't want the compiler or linker including anything more than I explicitly told it to include. If you disagree, well, hey, I guess we'll just have to agree to disagree. Cheers... Patrick Bennett

2 1

RE: [boost] Wave Bjam building problems\Joel de Guzman -did youeverfind a solution?
by Brian Braatz 26 May '05

26 May '05

Hartmut- HI THERE! I must say, I am excited to get the build fun over with so I can use your extremely cool creation. Details: I am using V2. I am NOW much closer. I am compiling but NOT LINKING- I have removed VC70 COMPLETELY from my box and rebuilt boost with 71 (again). That an a using msvc : 7.1. : (path to cl.exe) in the user-config.jam got me to compile. Additionally, I went through and manually removed all of the references in my LIB, INCLUDE and PATH to vc70. This may sound extreme, but it allowed BJAM to compile (Bjam's interaction with those ENV vars is something I don't fully know how it works) I am now trying to build the quick start with the VC71 IDE My current problem is this link error: Linking... LINK : fatal error LNK1104: cannot open file 'libboost_wave-vc7-mt-gd-1_32.lib' Build log was saved at "file://c:\data\Irx\Irx\Arx\Main\Source\Common\Boost\V_1_32\libs\wave\sa mples\quick_start\Debug\BuildLog.htm" WaveQuickStart - 1 error(s), 0 warning(s) The LIB I have available is 'libboost_wave-vc71-mt-gd-1_32.lib not 'libboost_wave-vc7-mt-gd-1_32.lib'. I am not sure WHY the autolinking is trying to hit the vc70 version of the lib since I am using VC71's IDE. (ANYONE HAVE ANY SUGGESTIONS?) Additionally, I will try your suggestion below just to see what happens. THANK YOU Brian Braatz Info and tips for anyone who might find this mail in the archives: 1- Try to build the spirit example FIRST, if you cant build the examples with Spirit, you will not be able to get wave to compile 2- Remove all the references to other compilers in LIB, INCLUDE and PATH, this seemed to clean things up for me (though this SHOULD not be necessary I believe) 3- Maintain patience and perseverance. :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Hartmut Kaiser > Sent: Thursday, May 26, 2005 5:20 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Wave Bjam building problems\Joel de Guzman -did > youeverfind a solution? > > > Brian, > > IIRC, removing the /GR switch (generate RTTI) should solve the problem. > > But the Wave jamfiles in the Boost CVS:HEAD should work fine, didn't they? > Anyway, I'll retry to compile it today based on the Boost 1.32 release. > > Are you using Build V1 or V2? Joel reported the error went away after > switching to the V1 Jamfiles. > > Regards Hartmut > > > > Attempting to BUILD WAVE, I have spent the last few hours > > (midnight til > > 5am) searching the archives and trying different things. ( > > the below email is the exact problem I am having) > > > > I have tried both the review version of wave and the one in > > CVS applied to the 1.32 release. I am using vc7.1 > > > > Has anyone found the issue below yet? > > > > Many thanks, > > > > Brian > > > > > > > -----Original Message----- > > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] > > > On Behalf Of Joel de Guzman > > > Sent: Sunday, February 13, 2005 2:55 PM > > > To: boost(a)lists.boost.org > > > Subject: [boost] Re: Wave review > > > > > > Hartmut Kaiser wrote: > > > > > > > > Joel de Guzman wrote: > > > > > > > >>+ when using bjam V2, VC7.1 fails with a buffer overrun > > (compiler > > > >> problem). No problem with bjam V1. I wanted to try > > the samples > > > >> but they don't have a V1 Jamfile, only V2. So I had to switch > > > >> to using g++ instead. So far so good. > > > > > > > > > > > > Sure they have, haven't they? I'm pretty sure that I've added V1 > > > Jamfile's. > > > > But thanks for reporting the V2 problems. Please add the line > > > > > > > > : <toolset>vc-7_1:<rtti>off # workaround for > > compiler bug > > > > > > > > to the V2 Jamfile's, without that VC7.1 simply fails - please look > > at > > > the V2 > > > > Jamfile of the library itself for a sample > > > > ($BOOST_ROOT/libs/wave/build/Jamfile.v2). > > > > > > Hi Hartmut, > > > > > > VC7.1 still bombs with "buffer overrun". Here's the bjam output: > > > > > > C:\dev\boost\libs\wave\build>bjam --v2 ...found 108 targets... > > > ...updating 5 targets... > > > msvc.compile.c++ > > > ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_gram > > > mar.obj > > > instantiate_cpp_grammar.cpp > > > > > > call "C:\Program Files\Microsoft Visual Studio .NET > > > 2003\Vc7\bin\vcvars32.ba t" > nul cl /Zm800 -nologo -TP > > > -DBOOST_ALL_NO_LIB=1 /Z7 /Od /Ob0 /EHsc /GR > > > /MDd -I"C > > > :\dev\boost" -c > > > -Fo"..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_ > > > grammar.obj" "..\src\instantiate_cpp_grammar.cpp" > > > > > > ...failed msvc.compile.c++ > > > ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiat > > > e_cpp_grammar.obj... > > > > > > Did I do something wrong? > > > > > > -- > > > Joel de Guzman > > > http://www.boost-consulting.com > > > http://spirit.sf.net > > > > > > _______________________________________________ > > > Unsubscribe & other changes: > > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

3 3