[boost] Re: Release of 1.30.2 imminent
Jens Maurer [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] Fernando Cacciola wrote: Recently, Jens Maurer changed the guard at function scope from: #ifndef __GNUC__ to #ifndef BOOST_NO_STDC_NAMESPACE and honestly, I didn't looked much at it as I should. BOOST_NO_STDC_NAMESPACE is documented to relate to C names, but swap is a C++ name so I don't think such macro should be used here. The CVS change of optional.hpp:1.10 is definitely incorrect, because STDC_NAMESPACE refers to C names, not C++ names. Sorry. However, just reverting the patch will make gcc-3.3 non-functional, because std::swap(int,int) (for example) is not going to be found. I've checked in a better fix to the main branch. optional_test.cpp now works with gcc 2.95, gcc 3.0 and gcc 3.3 on Linux. Please test on other platforms and (optionally) transport the fix to the 1.30.0 CVS branch. Jens Maurer Actually, I had fix it for RC_1_30_0 already. If the release goes OK, I think I should merge my fix back to the main trunk. Thanks anyway. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
David Abrahams wrote: I have fixed the last regression (the one with crc_test) in CVS, so as soon as you've made your patch and we've had one more round of testing, I'm going to tag it for release. Please let me know the instant you're finished. Bad news, there is a new problem: One test uses an unportable filename: std::facet-support.test. Consequently, process_jam_log crashes due to an exception thrown by boost::filesystem::path. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Martin Wille [EMAIL PROTECTED] writes: David Abrahams wrote: I have fixed the last regression (the one with crc_test) in CVS, so as soon as you've made your patch and we've had one more round of testing, I'm going to tag it for release. Please let me know the instant you're finished. Bad news, there is a new problem: One test uses an unportable filename: std::facet-support.test. Consequently, process_jam_log crashes due to an exception thrown by boost::filesystem::path. The same here. The relevant lines from bjam.log are MkDir1 D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test mkdir D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test The parameter is incorrect. ...failed MkDir1 D:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test... ...skipped directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport for lack of directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test... ...skipped directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug for lack of directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport... ...skipped directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug\runtime-link-dynamic for lack of directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug... ...skipped directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug\runtime-link-dynamic\stlport-cstd-namespace-std for lack of directory-gristD:\boost2\rc_1_30_0\results\status\bin\std::facet-support.test\meta-intel-7.1-stlport\debug\runtime-link-dynamic... -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
Hi... Instead of downloading the complete Boost every time something has changed, why don't you consider 1.30.0 as a standard from subsequent releases until you reach 1.4.0 and so that we can only download only the modified libraries? Mohammed ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Martin Wille [EMAIL PROTECTED] writes: David Abrahams wrote: I have fixed the last regression (the one with crc_test) in CVS, so as soon as you've made your patch and we've had one more round of testing, I'm going to tag it for release. Please let me know the instant you're finished. Bad news, there is a new problem: One test uses an unportable filename: std::facet-support.test. Whaa?? There's not supposed to be a file with that name! It should be showing up in the test's requirements! Consequently, process_jam_log crashes due to an exception thrown by boost::filesystem::path. Will fix. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Mohamed Iqbal [EMAIL PROTECTED] writes: Hi... Instead of downloading the complete Boost every time something has changed, why don't you consider 1.30.0 as a standard from subsequent releases until you reach 1.4.0 and so that we can only download only the modified libraries? You can use CVS if you want to minimize the amount of downloading when upgrading. I don't think anyone wants the extra responsibility of preparing patchsets from 1.30.0 to whatever the next version is. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html So it should correspond to the HEAD revision. IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. I am only concerned with RC_1_30_0 here. I see. I think that the correct patch is to revert Jens' fix. (go back to revision 1.9). Can you and others run a quick test to see if this fix is correct? RC_1_30_0 already works with GCC-3.2 work for me. I see. I wonder what would happen with gcc3.3 and 3.3.1 without Jen's patch. Should I revert that anyway, even if it leaves those compilers unsupported? Are they healthier without the patch or with it? without it. Can you use BOOST_WORKAROUND to select the best answer for all GCC versions? Yes, I think. Though I cannot test it myself. How do I apply the patch? I mean, what do I do with CVS to have it on the right branch/tag. (I guess that if I just commit it, it won't end on the right place) Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Fernando Cacciola [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html So it should correspond to the HEAD revision. IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. I am only concerned with RC_1_30_0 here. I see. I think that the correct patch is to revert Jens' fix. (go back to revision 1.9). Can you and others run a quick test to see if this fix is correct? RC_1_30_0 already works with GCC-3.2 work for me. I see. I wonder what would happen with gcc3.3 and 3.3.1 without Jen's patch. Should I revert that anyway, even if it leaves those compilers unsupported? Are they healthier without the patch or with it? without it. Can you use BOOST_WORKAROUND to select the best answer for all GCC versions? Yes, I think. Though I cannot test it myself. How do I apply the patch? I mean, what do I do with CVS to have it on the right branch/tag. (I guess that if I just commit it, it won't end on the right place) cvs update -rRC_1_30_0 filenames... cvs edit filenames... [Make your changes] cvs commit filenames... # to get back to the main trunk: cvs update -A filenames... I have fixed the last regression (the one with crc_test) in CVS, so as soon as you've made your patch and we've had one more round of testing, I'm going to tag it for release. Please let me know the instant you're finished. Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: [sniped] How do I apply the patch? I mean, what do I do with CVS to have it on the right branch/tag. (I guess that if I just commit it, it won't end on the right place) cvs update -rRC_1_30_0 filenames... cvs edit filenames... [Make your changes] cvs commit filenames... # to get back to the main trunk: cvs update -A filenames... I have fixed the last regression (the one with crc_test) in CVS, so as soon as you've made your patch and we've had one more round of testing, I'm going to tag it for release. Please let me know the instant you're finished. Done. (I've also checked in a couple of typos in the doc that were reported to me) Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: Hi, There are still problems with Optional, related to some compilers not finding std swap(). I wrote the original code following compressed_pair.hpp, which is via unqualified call (to activate ADL), plus a using declaration at function scope for GCC. Recently, Jens Maurer patched it adding an alternative using declaration at namespace scope (optional_detail) for GCC, but this seems not to work as the regressions show. I don't have access to any of the failing compilers Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 On Linux_1_30_0: gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3.1 On Linux: All tests passed. (how come? On Libux-rc-1_30_0: gcc3.4: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.4-cvs gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3.1 On Win32_1_30_1: gcc: http://boost.sourceforge.net/regression-logs/cs-win32-1_30_1-links.html#optional_test-gcc On Win32: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-como-win32 VC60 : http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-msvc On Win32 metacomm: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-com o-4.3.2b-vc7 Intel 7.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1 Intel 7.0 STLPort: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1-stlport VC 6.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc VC 6.0 STLPort : http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc-stl port The following are errors in other dependent libraries (type_traits and mpl) On MAC OS: GNU-GCC: http://boost.sourceforge.net/regression-logs/cs-Darwin-links.html#optional_test_fail5a-darwin On HP-UX: aCC53800: http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#optional_test-acc aCC33380: http://boost.sourceforge.net/regression-logs/cs-hpux-links.html#optional_test-acc This is a compiler crash. On Solaris: http://boost.sourceforge.net/regression-logs/cs-solaris-links.html#optional_test-sunpro Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Peter Dimov [EMAIL PROTECTED] writes: Fernando Cacciola wrote: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 What's so surprising here? Everything fails exactly as it should. 1.30 has #ifndef __GNUC__ using std::swap; #endif and hence should fail on every non-broken GCC. HEAD has #ifndef BOOST_NO_STDC_NAMESPACE using std::swap; #endif instead and hence should fail on every BOOST_NO_STDC_NAMESPACE compiler that isn't a broken GCC. Are you suggesting these should all be replaced with simply: using std::swap; ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Fernando Cacciola [EMAIL PROTECTED] writes: I don't understand the problem with the original code (as of revision 1.19), and I don't understand why 1.30.0 fails. RC_1_30_0 is working for me with gcc-3.2 on Win32. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Release of 1.30.2 imminent
-Original Message- From: Fernando Cacciola [mailto:[EMAIL PROTECTED] Note: although this library is new, google shows (to my satisfaction) that there are already a couple of users of Optional out there. Simple and effective. It is in a production system here. Many thanks, Matt. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
David Abrahams wrote: Martin Wille writes: David Abrahams wrote: NOTICE: If I don't hear of any new problems with the RC_1_30_0 branch I'm going to release 1.30.2 tomorrow (Wed) evening or Thursday morning. Not new: there are still some regressions for Linux: crc_test regresses for gcc3.1 and gcc3.2.3 config_test regresses for intel 7.1 (clock_gettime function isn't found) format tests (all of them) regress for intel 7.1 ios_state_test regresses for intel 7.1 The format tests and ios_state_test fail due to a linker error. Apparently, the tests need to be linked against pthreads. Since Daryle and Samuel haven't been responsive about these, I guess I have to ask you if you'd like the opportunity to try to fix them before we ship... Are you interested? The config_test regression was caused by not having linked against librt. I added these lines to intel-linux.jam on the RC_1_30_0 branch: # required libraries flags intel-linux FINDLIBS : rt ; The HEAD version of intel-linux.jam already contains those lines. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: |Just out of curiosity. What the heck is librt? | | | It contains the POSIX realtime feature set (used by boost.threads, and hence | tested by boost.config for timeouts and thread priorities and the like). Ahhh.. Thanks! Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/O2ny0ds/gS3XsBoRAgmqAJ48W8mgnaD0xDKjiE8SwfyjOmGI1gCfdYlW Bj4/UnUt8H5aVe6xWC5xI+k= =+0Iq -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: There are still problems with Optional, related to some compilers not finding std swap(). I wrote the original code following compressed_pair.hpp, which is via unqualified call (to activate ADL), plus a using declaration at function scope for GCC. Recently, Jens Maurer patched it adding an alternative using declaration at namespace scope (optional_detail) for GCC, but this seems not to work as the regressions show. I don't have access to any of the failing compilers Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 Well, 3.4 isn't even a released compiler so As far as I'm concerned it doesn't count. OK. 3.3.x is another story. and VC==6.0 Hmm. It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 On Linux_1_30_0: gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3.1 snip Unfortunately, nearly all of these links point to invalid targets so my browser doesn't find them :(. Could you just post links to the summary page one level up? Sure. From the main status page, at: http://boost.sourceforge.net/regression-logs/ The link that reads (Linux-1_30_0), under the title Linux, goes to: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0.html There are the failures I've shown for gcc3.3 and gcc3.3.1 This page shows the regression for 1.30.0 right? But they show that the newer gcc failed (without Jens patch). On Linux: All tests passed. (how come? I'm not sure what you mean. If it doesn't say 1_30_0 in the page it's probably a test of the HEAD revision. The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html So it should correspond to the HEAD revision. IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. I wonder if the reports are swaped (the page titled 1.30.0 being the HEAD and viceversa) On Libux-rc-1_30_0: ^ ? gcc3.4: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.4-cvs gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3.1 Aren't these the same tests as cited above? Not exactly. This result appears in the page: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0.html which is the third Linux report from the main page. On Win32_1_30_1: gcc: http://boost.sourceforge.net/regression-logs/cs-win32-1_30_1-links.html#optional_test-gcc Yeah, the fix by Jens looks broken to me. Jens, to which versions of GCC does this patch apply? It was intended for 3.3 as he told me. I think that the correct patch is to revert Jens' fix. (go back to revision 1.9). Can you and others run a quick test to see if this fix is correct? Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
David Abrahams wrote: Martin Wille writes: David Abrahams wrote: NOTICE: If I don't hear of any new problems with the RC_1_30_0 branch I'm going to release 1.30.2 tomorrow (Wed) evening or Thursday morning. Not new: there are still some regressions for Linux: crc_test regresses for gcc3.1 and gcc3.2.3 config_test regresses for intel 7.1 (clock_gettime function isn't found) format tests (all of them) regress for intel 7.1 ios_state_test regresses for intel 7.1 The format tests and ios_state_test fail due to a linker error. Apparently, the tests need to be linked against pthreads. Since Daryle and Samuel haven't been responsive about these, I guess I have to ask you if you'd like the opportunity to try to fix them before we ship... Are you interested? Sorry, I'm swamped with other stuff, already. The link failures for the format tests and the ios_state_test likely isn't an indication of a problem in the respective libraries. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
Fernando Cacciola wrote: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 What's so surprising here? Everything fails exactly as it should. 1.30 has #ifndef __GNUC__ using std::swap; #endif and hence should fail on every non-broken GCC. HEAD has #ifndef BOOST_NO_STDC_NAMESPACE using std::swap; #endif instead and hence should fail on every BOOST_NO_STDC_NAMESPACE compiler that isn't a broken GCC. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
Fernando Cacciola wrote: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ... Well, 3.4 isn't even a released compiler so As far as I'm concerned it doesn't count. I added 3.4 only for informational purpose. There is no point in actively support a compiler that is still under development. I'm not sure what you mean. If it doesn't say 1_30_0 in the page it's probably a test of the HEAD revision. The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html So it should correspond to the HEAD revision. IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. I wonder if the reports are swaped (the page titled 1.30.0 being the HEAD and viceversa) No, I checked my scripts, they aren't swapped. To clarify: cs-Linux are the tests for cvs head. cs-Linux-1.30.0 are the tests for 1.30.0 RELEASE. cs-Linux-rc-1.30.0 are the tests for the RC_1_30_0 branch. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Hi, There are still problems with Optional, related to some compilers not finding std swap(). I wrote the original code following compressed_pair.hpp, which is via unqualified call (to activate ADL), plus a using declaration at function scope for GCC. Recently, Jens Maurer patched it adding an alternative using declaration at namespace scope (optional_detail) for GCC, but this seems not to work as the regressions show. I don't have access to any of the failing compilers so I cannot fix it myself. If anyone can do it, we might have this fixed for 1.30.2. Note: although this library is new, google shows (to my satisfaction) that there are already a couple of users of Optional out there. TIA Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: Fernando Cacciola wrote: Most problems related to swap ocurr with GCC3.3 and VC==6.0 It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 What's so surprising here? Everything fails exactly as it should. 1.30 has #ifndef __GNUC__ using std::swap; #endif and hence should fail on every non-broken GCC. HEAD has #ifndef BOOST_NO_STDC_NAMESPACE using std::swap; #endif instead and hence should fail on every BOOST_NO_STDC_NAMESPACE compiler that isn't a broken GCC. Are you suggesting these should all be replaced with simply: using std::swap; ?? I don't know what was the original motivation for #ifdef-ing the using declaration, but my g++ 2.95.3 seems to eat it just fine, if this is any indication. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Wille wrote: | David Abrahams wrote: | | | The config_test regression was caused by not having linked against | librt. I added these lines to intel-linux.jam on the RC_1_30_0 branch: Just out of curiosity. What the heck is librt? Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/O1lD0ds/gS3XsBoRAsU5AJ4gY6y2AozxySczPbLwR1M26b+YgQCfWiBB qPGiYaI3OSu4cKMuYNX5acQ= =YoJd -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html So it should correspond to the HEAD revision. IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. I am only concerned with RC_1_30_0 here. I see. I think that the correct patch is to revert Jens' fix. (go back to revision 1.9). Can you and others run a quick test to see if this fix is correct? RC_1_30_0 already works with GCC-3.2 work for me. I see. I wonder what would happen with gcc3.3 and 3.3.1 without Jen's patch. Should I revert that anyway, even if it leaves those compilers unsupported? I checked in this patch to fix vc6/7: Great. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
On Wed, 2003-08-13 at 16:50, Martin Wille wrote: The link failures for the format tests and the ios_state_test likely isn't an indication of a problem in the respective libraries. I was in holidays, sorry I did not respond earlier. I gave a look at the regression reports, and indeed the pthread linking problem must be rather unrelated to the code itself in format, which doesnt call any thread function. I suspect it's because the tests are linked statically (because of wchar issues whith some compiler), and it triggers something. Does anyone have a clue on what to do to fix this ? I attach a snippet of the reports from http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#format_test1-intel-7.1 Regards, -- Samuel format_test1 / intel-7.1 Linker output: /opt/intel/compiler70/ia32/lib/libcprts.a(xmtx.o)(.text+0x73): In function `_Mtxinit': : undefined reference to `pthread_mutex_init' [...] /opt/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' . /opt/intel/compiler70/ia32/bin/iccvars.sh icc -g -static -o ../libs/format/test/bin/format_test1.test/intel-7.1/debug/runtime-link-static/format_test1 ../libs/format/test/bin/format_test1.test/intel-7.1/debug/runtime-link-static/format_test1.o ../libs/test/build/bin/libboost_test_exec_monitor.a/intel-7.1/debug/runtime-link-static/libboost_test_exec_monitor.a ../libs/test/build/bin/libboost_test_exec_monitor.a/intel-7.1/debug/runtime-link-static/libboost_test_exec_monitor.a -lrt ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
On Tue, 12 Aug 2003 22:15:28 -0700, Stephan T. Lavavej wrote
[Dave Abrahams]
If I don't hear of any new problems with the RC_1_30_0 branch I'm
going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.
There's one little problem... it doesn't compile cleanly under
-Wshadow with gcc. This is annoying because it forces the user to:
1. Hack the headers to eliminate the warning (ugh, even if it's
trivial)
If the headers are unhackable (e.g. someone else is root), then:
2. Mentally ignore the warning (ugh)
3. Stop using the warning (ugh)
The offending part is line 24 of boost/date_time/date_duration.hpp.
Which is:
explicit date_duration(duration_rep days) : days_(days) {};
This causes problems because the very next line defines a function
identically named to that duration_rep argument:
duration_rep days() const
gcc complains:
warning: declaration of `days' shadows a member of `this'
The fix is trivial: change the occurrences of days in line 24 to d.
days_ of course should not be modified.
There are presumably other -Wshadow problems elsewhere in Boost, but
this is the only one that has affected my code so far.
Steven -
A warning under 1 option of one compiler that has been there all along
isn't enough to stop 1.30.2. I'm not going to check in that change because
I've been making plenty other of changes and I don't want to do anything that
might destabalize 1.30.2. Besides, I would not want to impose any additional
delay for Dave and others by forcing another round of regression testing
before the release.
If you have to have this fixed, you should use the latest CVS where I have
checked in the change (may be 24 hours propagation delay for anonymous
download). This will also allow you to pick up the new from_time_t function
and the new total_seconds functions we dicussed last week. If you're not
comfortable with that then fix it yourself for now and wait for 1.31 for the
final fix.
Jeff
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
The link failures for the format tests and the ios_state_test likely isn't an indication of a problem in the respective libraries. I was in holidays, sorry I did not respond earlier. I gave a look at the regression reports, and indeed the pthread linking problem must be rather unrelated to the code itself in format, which doesnt call any thread function. I suspect it's because the tests are linked statically (because of wchar issues whith some compiler), and it triggers something. Does anyone have a clue on what to do to fix this ? Very likely you are using something like shared_ptr or regex that make themselves thread safe when BOOST_HAS_THREADS is defined, if this is the case then adding either: defineBOOST_DISABLE_THREADS=1 or threadingmulti To the build requirements of the test will fix that. If you don't depend on any boost lib that uses threads, then I would guess that the culprit would be the std lib used (probably synchronises it's iostream code somewhere), in which case you're going to need to use the second option above. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
Just out of curiosity. What the heck is librt? It contains the POSIX realtime feature set (used by boost.threads, and hence tested by boost.config for timeouts and thread priorities and the like). John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
[Jeff Garland] I'm not going to check in that change because I've been making plenty other of changes and I don't want to do anything that might destabalize 1.30.2. Besides, I would not want to impose any additional delay for Dave and others by forcing another round of regression testing before the release. Okay, I can understand that. you should use the latest CVS where I have checked in the change Great; if the fix will appear in 1.31, then I'm happy. I can hack 1.30.x for myself until then. the new from_time_t function and the new total_seconds functions we dicussed last week. Whee! Stephan T. Lavavej http://stl.caltech.edu ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
Thomas Witt wrote: Martin Wille wrote: | David Abrahams wrote: | | | The config_test regression was caused by not having linked against | librt. I added these lines to intel-linux.jam on the RC_1_30_0 branch: Just out of curiosity. What the heck is librt? It contains the implementation of the (optional) POSIX TMR functionality, AFAICS. clock_gettime() (the function that wasn't found during linking) belongs to TMR. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Fernando Cacciola [EMAIL PROTECTED] writes: Hi, There are still problems with Optional, related to some compilers not finding std swap(). I wrote the original code following compressed_pair.hpp, which is via unqualified call (to activate ADL), plus a using declaration at function scope for GCC. Recently, Jens Maurer patched it adding an alternative using declaration at namespace scope (optional_detail) for GCC, but this seems not to work as the regressions show. I don't have access to any of the failing compilers Which compilers are failing and where are the regression report pages? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Fernando Cacciola [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: There are still problems with Optional, related to some compilers not finding std swap(). I wrote the original code following compressed_pair.hpp, which is via unqualified call (to activate ADL), plus a using declaration at function scope for GCC. Recently, Jens Maurer patched it adding an alternative using declaration at namespace scope (optional_detail) for GCC, but this seems not to work as the regressions show. I don't have access to any of the failing compilers Which compilers are failing and where are the regression report pages? Sorry for the delay, I was leaving the office when you posted this Most problems related to swap ocurr with GCC3.3 Well, 3.4 isn't even a released compiler so As far as I'm concerned it doesn't count. 3.3.x is another story. and VC==6.0 Hmm. It appears that this problem ocurrs both with 1.30.0 and the current rc 1.30.2 On Linux_1_30_0: gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-1_30_0-links.html#optional_test gcc-3.3.1 snip Unfortunately, nearly all of these links point to invalid targets so my browser doesn't find them :(. Could you just post links to the summary page one level up? On Linux: All tests passed. (how come? I'm not sure what you mean. If it doesn't say 1_30_0 in the page it's probably a test of the HEAD revision. On Libux-rc-1_30_0: ^ ? gcc3.4: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.4-cvs gcc3.3: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3 gcc3.3.1: http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0-links.html#optional_test gcc-3.3.1 Aren't these the same tests as cited above? On Win32_1_30_1: gcc: http://boost.sourceforge.net/regression-logs/cs-win32-1_30_1-links.html#optional_test-gcc Yeah, the fix by Jens looks broken to me. Jens, to which versions of GCC does this patch apply? On Win32: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-como-win32 VC60 : http://boost.sourceforge.net/regression-logs/cs-win32-links.html#optional_test-msvc This two are truly odd. I'm going to install Comeau here and see if I can reproduce it on both compilers. On Win32 metacomm: Comeau 4302: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-com o-4.3.2b-vc7 Same problem as above. I'm beginning to think it wasn't run on the same code I have on my disk. Intel 7.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1 Intel 7.0 STLPort: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-meta-int el-7.1-stlport VC 6.0: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc VC 6.0 STLPort : http://boost.sourceforge.net/regression-logs/cs-win32_metacomm-links.html#optional_test-msvc-stl port OK, I think I've fixed all of the above. The following are errors in other dependent libraries (type_traits and mpl) On MAC OS: GNU-GCC: http://boost.sourceforge.net/regression-logs/cs-Darwin-links.html#optional_test_fail5a-darwin Feh. The Darwin compiler is broken almost beyond repair. Ask Ralf Grosse-Kunstleve to tell you of his heroic efforts. On HP-UX: aCC53800: http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#optional_test-acc aCC33380: http://boost.sourceforge.net/regression-logs/cs-hpux-links.html#optional_test-acc This is a compiler crash. aCC is definitely broken beyond repair. I'm not going ot worry about that On Solaris: http://boost.sourceforge.net/regression-logs/cs-solaris-links.html#optional_test-sunpro This one is also a compiler crash, so... ditto -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
Samuel Krempp wrote: format_test1 / intel-7.1 Linker output: /opt/intel/compiler70/ia32/lib/libcprts.a(xmtx.o)(.text+0x73): In function `_Mtxinit': undefined reference to `pthread_mutex_init' [...] /opt/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': undefined reference to `pthread_mutex_unlock' These are probably caused by an upgraded glibc. It no longer exports weak pthread_* stubs. Apparently this is a feature and not a bug in glibc. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Fernando Cacciola [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Fernando Cacciola [EMAIL PROTECTED] writes: The page is: http://boost.sourceforge.net/regression-logs/cs-Linux.html So it should correspond to the HEAD revision. IIUC, the HEAD revision contains Jen's broken patch, so this one should fail. I am only concerned with RC_1_30_0 here. I see. I think that the correct patch is to revert Jens' fix. (go back to revision 1.9). Can you and others run a quick test to see if this fix is correct? RC_1_30_0 already works with GCC-3.2 work for me. I see. I wonder what would happen with gcc3.3 and 3.3.1 without Jen's patch. Should I revert that anyway, even if it leaves those compilers unsupported? Are they healthier without the patch or with it? Can you use BOOST_WORKAROUND to select the best answer for all GCC versions? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
