July 2004 - Boost - lists.preview.boost.org

Boost.Threads static linking FYI
by Michael Glassford 19 Jul '04

19 Jul '04

I've made some changes to the Boost.Threads static linking support on Win32. Previously I had added back support for static linking, but without thread-specific storage classes. Now I've added the thread-specific storage classes back in, and exposed two functions that need to be called at the appropriate time: The function on_thread_exit() should be called when a thread exists, *in the context of the exiting thread*. The function on_process_exit() should be called when the process exit. If these functions are not called at the appropriate time, leaks may occur. If you know you don't need tss cleanup, of course you can just omit to call these functions. In addition, Boost.Threads static library on Win32 requires the user of the library to define a function called tss_cleanup_implemented(); if it is not defined, a link error results. The only purpose of this function is as a "link-time assertion": the linker error stating that the function is missing warns the the user of the necessity of calling the cleanup functions. In addition, if Boost.Threads later implements tss cleanup in the static library, the linker's duplicate symbol error should warn the user that their custom implementation is no longer needed. Comments? Mike

5 11

Re:[boost] [serialization] CW problems...
by Robert Ramey 19 Jul '04

19 Jul '04

>Rene Rivera wrote: >> Robert Ramey wrote: >> >>> While your looking at CW, might you find the time to look a little bit >>> into >>> the serialization library build problems. The error message is pretty >>> bizarre so I don't think it can be addressed without having CW >>> installed on >>> ones machine. >> >> OK, I'll try... Should I look for anything in specific? Or is it a >> general health issue? >I'm looking at this and one of the basic problems is that you seem to >assume a variety of things are available in the global namespace, >specifically size_t and other std types. Those are easy to fix by >specifying std::size_t. But I do have some questions... >1. Is using an unqualified size_t your intention? And therefore >something else is broken? Wow - its amazing to me I could have come so far and not know that size_t wasn't a built in type or macro - I think it used to be a macro definition. Anyway, I'll qualify this with std::size_t and check that no other compilers complain. If fact, now I can't understand why no other compiler complained since I never included <cstddef> >2. There is a similar problem with mbstate_t, but in this case you >attempt to do something special to handle it (from >boost/archive/codecvt_null.hpp): >#if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) > #ifndef _RWSTD_NO_NAMESPACE > using std::codecvt; > using std::min; > #ifdef _RWSTD_NO_MBSTATE_T > using std::mbstate_t; > #endif > #endif >#elif defined(__COMO__) || defined(_MSC_VER) && _MSC_VER <= 1300 || >defined(__BORLANDC__) > typedef ::mbstate_t mbstate_t; >#elif defined(BOOST_NO_STDC_NAMESPACE) > typedef std::mbstate_t mbstate_t; > namespace std{ > using ::codecvt; > } // namespace std >#endif >And then you go ahead to use an unqualified mbstate_t. This just doesn't >work for CW. And I don't see how this would work for any library runtime >that puts mbstate_t only in the std namespace. Could you explain what >your intent is for this? The situation with mbstate_t is problematic. Some compilers define it in the global namespace while others define it in std::mbstate_t. The intent is to permit the code to use mbstate_t without qualification for those compilers that don't define it as std::mbstate_t. This sort of grew one compiler at time without too much thought. The typedef ::mbstate_t mbstate_t makes me wonder what I was thinking. Following the logic here for CW this would add #elif defined(CW) using std::mbstate_t; so that the rest of the code could use unqualified mbstate_t . I'll fix this (and a bunch other stuff) and we'll try again later. Thanks a lot. Robert Ramey

6 11

Bjam won't build thread static library VC .NET
by Tonko Juricic 19 Jul '04

19 Jul '04

First excuse me if this topic is not appropriate for boost developers list. This is my first post so I decided on asking a question rather than sending an empty message with test as a subject. I just built boost 1.31.0 libraries on Windows XP, using Visual Studio .NET 2003, compiler version 13.10.3077. To build both static libs and dlls I used this bjam command parameter -sBUILD=debug release <runtime-link>static/dynamic. Build worked just fine for all libs (for ex. I got both libboost_signals.lib and boost_signals.dll targets for signals) except for the thread library that created only boost_thread.dll target. What am I missing? Is there a reason that static threads library was not built and is there any way I can help? Tony __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

3 2

[date-time] not showing up in nightly CVS boostbook?
by Jeff Garland 19 Jul '04

19 Jul '04

I checked in a change to switch date-time over to boostbook (added to the docs/src/boost.xml file), but I haven't seen it show up on the web site yet. Is this not being run / uploaded on the weekend? Jeff

2 2

numeric/conversion/detail/meta: void_ in boost::mpl namespace
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Is BOOST_MPL_AUX_VOID_SPEC_PARAM supposed to be used by other libraries than MPL? The conversion library uses it (it is the only one to use it) and it obviously results in an error since void_ is in the boost::mpl namespace. This error is flagged by GCC, CodeWarrior, Como, and Intel (Linux). I won't suggest a patch since I'm not even sure to understand what this macro is supposed to do (is there any documentation or is it an undocumented internal macro?), but it can't be a bad thing to remove any reference to BOOST_MPL_AUX macros from the conversion library. Regards, Guillaume

2 1

Another regression testing problem.
by Martin Wille 19 Jul '04

19 Jul '04

Hi, I ran into another (small) problem with regression testing: Unpacking the tar-ball containing the XSL based reports takes approximately 1 hour on the (not very busy) SF shell server. The tar-ball is only 60MB in size, but it contains ~24000 files, which could explain why it takes that long. Is there any way to reduce the number of files? Regards, m

2 1

RE: [boost] uBLAS regressions
by Michael Stevens 19 Jul '04

19 Jul '04

On Monday 19 July 2004 09:51, Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> wrote: > Unfortunately, it did -- it was producing a composite library name > with back instead of forward slashes ("numeric\ublas" instead of > "numeric/ublas"), and that confused process_jam_log, causing uBLAS > disappear from the report. > > Fixed in the CVS now, together with a test case to prevent future > disturbance ("tools\build\v1\test\test-testing.jam"). Thanks Aleksey! It was noticed by me and a couple of others that it dropped out from the report. Just show people look at the reports everyday. They are very useful and your effort is very much appreciated. The developer format reports are really very clear and informative. One question. The Comeau tests seem to be in VC7 compatability mode. For me this is a bit of a shame as it is the only Comeau regression test and I would love to know how well we do in strict mode! > For no good reason, IMO. To uBLAS maintainers -- can we fix it > sometime after the release? Certainly will. The layout was historical! All the best, Michael

1 0

program_options & mingw - patch
by Janusz Piwowarski 19 Jul '04

19 Jul '04

Hello, i attach a patch which allows to compile program_options library with mingw. Regards, Janusz

2 1

spirit/iterator/multi_pass: end iterator dereferenced
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Lines 572-573 of multi_pass.hpp are: ensure_initialized(); return !data || data->input == InputT(); The code tries to read data in ensure_initialized even when testing for end of file (which means the input iterator is invalid). So here comes a patch. Regards, Guillaume

2 1

RE: [boost] uBLAS regressions
by Aleksey Gurtovoy 19 Jul '04

19 Jul '04

Vladimir Prus writes: > Aleksey Gurtovoy wrote: > > > > local rule get-library-name ( path ) > > > { > > > local match1 = [ MATCH [/\\]libs[/\\](.*)[/\\]test > : $(path) ] ; > > > > > > I'm not sure: > > > > > > ghost@zigzag:/tmp$ bjam -f- > > > ECHO [ MATCH [/\\]libs[/\\](.*)[/\\]test : > > > bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test ] ; > > > numeric\ublas\test1 > > > > > > > > > It's numeric\ublas\test1, not numeric\ublas. > > > > 'get-library-name' will be passed > > "bin\\boost\\libs\\numeric\\ublas\\test1", though, not > > "bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test". > > Well, first of all, when I create a separate test Jamfile for uBLAS > and subinclude it, I get: > > Cannot extract library name from path ../libs/numeric/ublas > > This is because when it's in status, 'get-library-name' just returns > empty string. When it's not in status, the 'get-library-name' rule > is called with > > ../libs/numeric/ublas > > and the first regex does not match because there's no "test" in the > name, and second regex does not match because there is slash between > "numeric" and "ublas". I've applied the attached patch -- since it > strictly adds the set of arguments to 'get-library-name' on which > that function does not fail, I think it should not cause any > problems. Unfortunately, it did -- it was producing a composite library name with back instead of forward slashes ("numeric\ublas" instead of "numeric/ublas"), and that confused process_jam_log, causing uBLAS disappear from the report. Fixed in the CVS now, together with a test case to prevent future disturbance ("tools\build\v1\test\test-testing.jam"). > > Another question whether all libraries should have their test > Jamfiles under "test" directory Yes, http://www.boost.org/more/lib_guide.htm#Directory_structure. > -- which is not what uBLAS does. For no good reason, IMO. To uBLAS maintainers -- can we fix it sometime after the release? > > And now back to original question. As I understand, the > 'get-library-name' rules gets the location of *Jamfile*. No, it is passed the location of the *target output directory*. > The primary heuristic is that location is "libs/ <library-name> / > test / whatever". Why can't this logic be applied to the name of > source file which bjam prints -- and be implemented in > process_jam_log. Nope, see my original posting -- http://article.gmane.org/gmane.comp.lib.boost.devel/105382. > > I'm asking because it seems to be that it's better to have smart > logic in process_jam_log than in jam. Sure, but in this case testing.jam is the only source of the information. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0