- Boost - lists.boost.org

[build] gcc version detection problem
by Glenn Schrader 04 Jan '07

04 Jan '07

Hello, This problem cropped up a couple of days ago when I updated my copy of the head version. The following is a piece of the output that I get when I run configure then make on either Linux or Solaris: ...patience... ...found 1921 targets... ...updating 695 targets... MkDir1 bin.v2 MkDir1 bin.v2/libs MkDir1 bin.v2/libs/iostreams MkDir1 bin.v2/libs/iostreams/build MkDir1 bin.v2/libs/iostreams/build/gcc-4.1.1 Copyright MkDir1 bin.v2/libs/iostreams/build/gcc-4.1.1 Copyright/release MkDir1 bin.v2/libs/iostreams/build/gcc-4.1.1 Copyright/release/threading-multi gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.1.1 Copyright/release/threading-multi/zlib.o The problem starts with the fifth MkDir1 line that contains '/gcc-4.1.1\nCopyright'. If I look in bin.v2/libs/iostreams/build I indeed see a subdirectory with an embedded newline in its name. After a bit of poking this fragment of the path appears to be created in tools/build/v2/tools/gcc.jam with the following lines: local command-string = $(command:J=" ") ; local command-info = [ MATCH "^[^ ]+[ ]+[^ ]+[ ]+([^ ]+)[^(]*[(]?([^)]*)" : [ SHELL "$(command-string) --version" ] ] ; version ?= $(command-info[1]) ; Using ECHO to see what the values are I get: ECHO "command-string = '$(command-string)'" ; command-string = 'g++' local ci = [ SHELL "$(command-string) --version" ] ; ECHO "ci = '$(ci)'" ; ci = 'g++ (GCC) 4.1.1 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ' The value of 'ci' is the same as what I get from running 'g++ --version' at a command line so that is OK. ECHO "version = '$(version)'" ; version = '4.1.1 Copyright' The value of 'version' matches what I'm seeing in the paths that are being generated. It looks to me like MATCH is interpreting its regex such that the term '([^ ]+)' (near the 19th char into the expression) is including the newline between '4.1.1' and 'Copyright'. There is some logic to this since a space isn't a newline but my copy of head from a month or so ago didn't have this problem. I checked and gcc.jam changed but this portion of the file didn't. Have any changes been made to bjam in the last month or so that would affect the behavior of MATCH? -glenn

1 0

[boost::thread] program throws thread_resource_error on sun/solaris
by Lars Kunert 04 Jan '07

04 Jan '07

I have written a prgram using boost::thread that works fine on a 32 and on a 64 bit linux machine. On a sun/solaris machine the program fails with the following message: >>terminate called after throwing an instance of 'boost::thread_resource_error' > > >> what(): boost::thread_resource_error >>Abort > > The sun/solaris machine: >>uname -a >>SunOS paris 5.9 Generic_118558-24 sun4u sparc SUNW,Sun-Fire-15000 > > I untared a fresh boost-package, build and tested it using: >>SRCDIR="/TL/usr/lkunert/src" >>BOOSTDIR="${SRCDIR}/boost/boost_1_33_1" >> >>cd ${BOOSTDIR} >> >>bjam \ >> "-sTOOLS=gcc" \ >> "-sGCC_ROOT_DIRECTORY=${SRCDIR}/sun64/gcc-3.4" \ >> "-sGXX=g++-3.4" \ >> "-sGCC=gcc-3.4" \ >>\ >> "-sBUILD=<cxxflags>-m64 <linkflags>-m64 debug release" \ >>\ >> "--without-python" \ >> "--with-unit_test" \ >> "--with-thread" > > and >>bjam \ >>... \ >>test > > The build returned no errors: >>... >>ar: creating >>bin/boost/libs/thread/build/libboost_thread.a/gcc/release/threading-multi/libboost_thread-gcc-mt-1_33_1.a >>...updated 71 targets... > > The test worked well too: >>Building Boost.Regex with the optional Unicode/ICU support disabled. >>Please refer to the Boost.Regex documentation for more information >>(and if you don't know what ICU is then you probably don't need it). >>...found 2 targets... > > In my project I do not use bjam, but autoconf/automake. In order to test boost::thread by hand, I compiled some of the files in boost/libs/thread/test by hand... >>${SRCDIR}/sun64/gcc-3.4/bin/g++-3.4 \ >>-I. \ >>-I${SRCDIR}/sun64/include \ >>-I${SRCDIR}/sun64/include/boost-1.33.1 \ >>-O3 -DNDEBUG -m64 -Wall \ >>-L${SRCDIR}/sun64/lib/boost-1.33.1-g++-3.4 -lboost_thread-gcc-mt >>-lboost_unit_test_framework-gcc \ >>-R${SRCDIR}/sun64/lib/boost-1.33.1-g++-3.4 \ >>-o test_barrier \ >>test_barrier.cpp > > I get the following error message: >>Running 1 test case... >>unknown location(0): fatal error in "test_barrier": std::exception: >>boost::thread_resource_error >> >>*** errors detected in test suite "Boost.Threads: barrier test suite"; > > see standard output for details This is the same error I get from my own code. It seems, that the bjam-build systems does something right, that I do not know about. (Like linking to an addidtional library - but why do I not get a link-error.) I figured out, that boost::thread uses pthreads... >>BOOST_HAS_THREADS >>BOOST_HAS_PTHREADS > > are defined Thanks for your help, Lars Kunert

2 1

[BGL] copy_graph() failure. Was: Re: [BGL] make_filtered_graph() should accept const Graph&. from Dec 15 2006
by Vladimir Sykora 04 Jan '07

04 Jan '07

thanks Doug. Also something that bugs me is that: typedef adjacency_list<...> G; G g; const G& cg = g; G f; boost::copy_graph(boost::make_filtered_graph(cg, ...), f); copy_graph() doesn't work if make_filtered_graph() is called with a const graph. boost::copy_graph(boost::make_filtered_graph(g, ...), f); works fine. gcc gives an error during casting to (const G&) in the get() function for filtered_graph<> (filtered_graph.hpp line 440). I'm not sure why is so, but definitely should work with a const Graph. Can you check this? thanks, --vjs Douglas Gregor wrote: > > On Tue, 2006-11-28 at 10:34 +0000, Vladimir Sykora wrote: >> >> Can anyone correct the make_filtered_graph() function on >> >> boost/graph/filtered_graph.hpp to accept a const Graph& ? > > > > So, you can pass a temporary to make_filtered_graph? Yeah, that should > > work. I'll add an overload. > > > > The intent of the current approach is to keep the cv-qualification of > > the graph that's passed in. > > > > adjacency_list<...> g; > > > > foo(make_filtered_graph(g, ...)); // filtered_graph of non-const g > > > > const adjacency_list<...>& gc = g; > > foo(make_filtered_graph(gc, ...)); // filtered_graph of const g > > > > Cheers, > > Doug > > > >

1 0

Submit to "Who's Using Boost?"
by Dai Hui 04 Jan '07

04 Jan '07

The name of the Application: Clipboard Recorder (http://www.lw-works.com/clipboard-recorder) The name of the company: LW-WORKS Software (http://www.lw-works.com) A paragraph describing the Application: Clipboard Recorder is an application that helps users to manage their clipboard history and provides easy ways for users to access their saved clipboard data. Libraries used: Smart Pointer, Serialization, Asio, String Algorithms, Bind, Thread, Conversion/Cast, Iostreams Regards, Dai Hui -- LW-WORKS Software - Creator of Clipboard Recorder Windows Clipboard utility

2 1

[Threads] Language extensions + MSVC (possible patch with new config)
by Sohail Somani 04 Jan '07

04 Jan '07

Any opinions on this? It is a patch against 1.33.1. It is meant to be non-intrusive: nothing should change unless you want it to. The idea is that when building boost threads, you require language extensions via your silence on BOOST_NO_REQUIRE_LANGUAGE_EXTENSIONS but if you are not building boost threads, you don't need language extensions. The idea is that BOOST_DISABLE_WIN32 does not need to be defined if language extensions are not needed. I would appreciate any feedback towards a possible patch. I am currently running the boost thread tests and hoping that they don't fail ;) If all goes well, I will rebuild the rest of boost as well and run tests there. Index: boost/config/compiler/visualc.hpp =================================================================== --- boost/config/compiler/visualc.hpp (revision 322) +++ boost/config/compiler/visualc.hpp (working copy) @@ -99,7 +99,7 @@ // disable Win32 API's if compiler extentions are // turned off: // -#ifndef _MSC_EXTENSIONS +#if !defined(_MSC_EXTENSIONS) && !defined(BOOST_NO_REQUIRE_LANGUAGE_EXTENSIONS) # define BOOST_DISABLE_WIN32 #endif Index: boost/thread/detail/config.hpp =================================================================== --- boost/thread/detail/config.hpp (revision 322) +++ boost/thread/detail/config.hpp (working copy) @@ -15,8 +15,20 @@ #include <boost/config.hpp> // insist on threading support being available: +// Don't need language extensions if we are not building boost +// threads +#if defined(BOOST_MSVC) && !defined(BOOST_BUILDING_THREADS) +# define BOOST_NO_REQUIRE_LANGUAGE_EXTENSIONS +# define DEFINED_BOOST_NO_REQUIRE_LANGUAGE_EXTENSIONS +#endif + #include <boost/config/requires_threads.hpp> +#if defined(DEFINED_BOOST_NO_REQUIRE_LANGUAGE_EXTENSIONS) +# undef BOOST_NO_REQUIRE_LANGUAGE_EXTENSIONS +# undef DEFINED_BOOST_NO_REQUIRE_LANGUAGE_EXTENSIONS +#endif + #if defined(BOOST_THREAD_BUILD_DLL) //Build dll #elif defined(BOOST_THREAD_BUILD_LIB) //Build lib #elif defined(BOOST_THREAD_USE_DLL) //Use dll Index: libs/thread/build/threads.jam =================================================================== --- libs/thread/build/threads.jam (revision 322) +++ libs/thread/build/threads.jam (working copy) @@ -63,6 +63,7 @@ : ## requirements ## <sysinclude>$(BOOST_ROOT) <threading>multi + <define>BOOST_BUILDING_THREADS=1 <borland><*><cxxflags>-w-8004 <borland><*><cxxflags>-w-8057 : ## default build ##

2 1

Boost regression notification (2006-12-22 [RC_1_34_0])
by Douglas Gregor 04 Jan '07

04 Jan '07

Boost Regression test failures Report time: 2006-12-22T11:25:47Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 12 failures in 6 libraries concept_check (6) date_time (1) regex (1) statechart (1) test (2) utility (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 |date_time| testgenerators: qcc-3.3.5_gpp |regex| regex_regress_threaded: msvc-6.5 |statechart| TransitionTestNormal: intel-linux-9.0 |test| prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64

3 4

[Boost-bugs] [ boost-Patches-1627420 ] [thread] MSVS: Allow use of thread headers with /Za
by SourceForge.net 03 Jan '07

03 Jan '07

Patches item #1627420, was opened at 2007-01-03 15:17 Message generated for change (Comment added) made by sohail_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&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 Private: No Submitted By: sohail (sohail_) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] MSVS: Allow use of thread headers with /Za Initial Comment: The following code will not compile if built with /Za on Visual C++ 7.1+: #include <boost/thread/once.hpp> int main(){} It will fail with the following assertion: # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" The reason is that the Boost.Config machinery realizes that you cannot use the Windows API unless you enable language extensions. As a result, threads cannot be available. This is correct behaviour when you are indeed *using* the Windows API. However, in the above case where you separately compile the threads library, you do not actually use the Windows API => language extensions are not necessary => no need to explicitly specify BOOST_DISABLE_WIN32. I therefore submit that there be some machinery/configuration variables to allow libraries to specify whether or not they require the Windows API. The proposed patch does not modify existing behaviour. That is, if the config machinery decides that the API is needed, it is required, unless explicitly disabled. The code to do this in library xyz would look something like this: #if defined(BOOST_BUILDING_WHATEVER) # define BOOST_NO_REQUIRE_WIN32 #endif #include <boost/config.hpp> I am uncertain of the exact name of the macro that is required but I am certain a macro is required. The attached patch is against 1.33.1. I don't think there is any rush to put this into 1.34. I'm pretty sure it would be nice, but people can manually patch it until 1.35 whenever that is released. Thanks, Sohail ---------------------------------------------------------------------- >Comment By: sohail (sohail_) Date: 2007-01-03 15:40 Message: Logged In: YES user_id=1682817 Originator: YES File Added: boost_no_require_win32.patch ---------------------------------------------------------------------- Comment By: sohail (sohail_) Date: 2007-01-03 15:25 Message: Logged In: YES user_id=1682817 Originator: YES That should be: #if !defined(BOOST_BUILDING_WHATEVER) :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1627420 ] [thread] MSVS: Allow use of thread headers with /Za
by SourceForge.net 03 Jan '07

03 Jan '07

Patches item #1627420, was opened at 2007-01-03 15:17 Message generated for change (Comment added) made by sohail_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&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 Private: No Submitted By: sohail (sohail_) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] MSVS: Allow use of thread headers with /Za Initial Comment: The following code will not compile if built with /Za on Visual C++ 7.1+: #include <boost/thread/once.hpp> int main(){} It will fail with the following assertion: # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" The reason is that the Boost.Config machinery realizes that you cannot use the Windows API unless you enable language extensions. As a result, threads cannot be available. This is correct behaviour when you are indeed *using* the Windows API. However, in the above case where you separately compile the threads library, you do not actually use the Windows API => language extensions are not necessary => no need to explicitly specify BOOST_DISABLE_WIN32. I therefore submit that there be some machinery/configuration variables to allow libraries to specify whether or not they require the Windows API. The proposed patch does not modify existing behaviour. That is, if the config machinery decides that the API is needed, it is required, unless explicitly disabled. The code to do this in library xyz would look something like this: #if defined(BOOST_BUILDING_WHATEVER) # define BOOST_NO_REQUIRE_WIN32 #endif #include <boost/config.hpp> I am uncertain of the exact name of the macro that is required but I am certain a macro is required. The attached patch is against 1.33.1. I don't think there is any rush to put this into 1.34. I'm pretty sure it would be nice, but people can manually patch it until 1.35 whenever that is released. Thanks, Sohail ---------------------------------------------------------------------- >Comment By: sohail (sohail_) Date: 2007-01-03 15:25 Message: Logged In: YES user_id=1682817 Originator: YES That should be: #if !defined(BOOST_BUILDING_WHATEVER) :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1627420 ] [thread] MSVS: Allow use of thread headers with /Za
by SourceForge.net 03 Jan '07

03 Jan '07

Patches item #1627420, was opened at 2007-01-03 15:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&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 Private: No Submitted By: sohail (sohail_) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] MSVS: Allow use of thread headers with /Za Initial Comment: The following code will not compile if built with /Za on Visual C++ 7.1+: #include <boost/thread/once.hpp> int main(){} It will fail with the following assertion: # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" The reason is that the Boost.Config machinery realizes that you cannot use the Windows API unless you enable language extensions. As a result, threads cannot be available. This is correct behaviour when you are indeed *using* the Windows API. However, in the above case where you separately compile the threads library, you do not actually use the Windows API => language extensions are not necessary => no need to explicitly specify BOOST_DISABLE_WIN32. I therefore submit that there be some machinery/configuration variables to allow libraries to specify whether or not they require the Windows API. The proposed patch does not modify existing behaviour. That is, if the config machinery decides that the API is needed, it is required, unless explicitly disabled. The code to do this in library xyz would look something like this: #if defined(BOOST_BUILDING_WHATEVER) # define BOOST_NO_REQUIRE_WIN32 #endif #include <boost/config.hpp> I am uncertain of the exact name of the macro that is required but I am certain a macro is required. The attached patch is against 1.33.1. I don't think there is any rush to put this into 1.34. I'm pretty sure it would be nice, but people can manually patch it until 1.35 whenever that is released. Thanks, Sohail ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Now config macro : BOOST_NO_TWO_PHASE_NAME_LOOKUP
by AlisdairM 03 Jan '07

03 Jan '07

I have just supplied John with a new defect macro and test case to detect compilers that (do not) support 2-phase name lookup with templates, but it would be really helpful if someone who is more familiar with the problem (and access to conforming compilers!) can verify the test for us! The test case is in boost/libs/config/boost_no_two_phase_name_lookup.ipp and currently the code looks like: template< class T > struct base { int call() { return 1; } }; int call() { return 0; } template< class T > struct derived : base< T > { int call_test() { return call(); } }; int test() { derived< int > d; return d.call_test(); } I believe a conforming compiler should only find the 'free' function, where a broken compiler will typically call the function from its base class template. Also, beware of config test failures until the various compiler config headers are updated. This should also give us a good idea of whether the right compilers are being flagged! -- AlisdairM

4 4