[1.32 Release] New tarballs are available for testing
Updated draft tarballs for the 1.32 release are available from the following locations: http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip This update fixes a number of the issues reported earlier, including: - unconventional file/directory privileges (http://article.gmane.org/gmane.comp.lib.boost.devel/112582) - a bug in the filesystem library (http://article.gmane.org/gmane.comp.lib.boost.devel/112565) - missing listing of Program Options library (http://article.gmane.org/gmane.comp.lib.boost.devel/112571) - tarball unpacking problem in "regression.py" - broken links fixes - all other fixes that has been committed to the release branch during the last two days. Once again, for your convenience, the unpacked contents is available online at http://www.meta-comm.com/engineering/boost/1_32_0_draft/. You can consider this to be a draft version of post-1.32 Boost website. The updated list of known issues follows. KNOWN ISSUES ------------ The following is a list of known issues present in the tarballs which grant them their draft status: 1) A small number of unmarked test failures (but no regressions). 2) Two files with broken links as follows: libs/libraries.htm: broken link: ../doc/boost.pdf libs/python/doc/v2/reference.html: broken link: wrapper.html, broken link: wrapper.html#classes, broken link: wrapper.html#override-spec, broken link: wrapper.html#wrapper-spec 3) No documentation in PDF format ("boost.pdf") 4) Placeholder pages in place of the revoked pre-1.32 MPL documentation. If you encounter any issues that are not in the above list, please report them here! TESTING ------- Please see the original announcement for details -- http://article.gmane.org/gmane.comp.lib.boost.devel/112562 -- Aleksey Gurtovoy MetaCommunications Engineering
Could these patches be applied to make program_options compile with the IBM compiler? Matthias --- boost/boost/program_options/detail/utf8_codecvt_facet.hpp Wed Jul 21 09:49:15 2004 +++ ../utf8_codecvt_facet.hpp Tue Nov 2 15:05:34 2004 @@ -146,7 +146,11 @@ const char * from, const char * from_end, std::size_t max_limit +#if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) + ) const throw(); +#else ) const; +#endif // Largest possible value do_length(state,from,from_end,1) could return. virtual int do_max_length() const throw () { --- boost/libs/program_options/src/utf8_codecvt_facet.cpp Thu Aug 26 11:37:53 2004 +++ ../utf8_codecvt_facet.cpp Tue Nov 2 15:04:38 2004 @@ -172,7 +172,12 @@ const char * from, const char * from_end, std::size_t max_limit +#if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) +) const throw() +#else ) const +#endif + { // RG - this code is confusing! I need a better way to express it. // and test cases.
Matthias Troyer writes:
Could these patches be applied to make program_options compile with the IBM compiler?
Vladimir?
--- boost/boost/program_options/detail/utf8_codecvt_facet.hpp Wed Jul 21 09:49:15 2004 +++ ../utf8_codecvt_facet.hpp Tue Nov 2 15:05:34 2004 @@ -146,7 +146,11 @@ const char * from, const char * from_end, std::size_t max_limit +#if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) + ) const throw(); +#else ) const; +#endif
// Largest possible value do_length(state,from,from_end,1) could return. virtual int do_max_length() const throw () {
--- boost/libs/program_options/src/utf8_codecvt_facet.cpp Thu Aug 26 11:37:53 2004 +++ ../utf8_codecvt_facet.cpp Tue Nov 2 15:04:38 2004 @@ -172,7 +172,12 @@ const char * from, const char * from_end, std::size_t max_limit +#if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) +) const throw() +#else ) const +#endif + { // RG - this code is confusing! I need a better way to express it. // and test cases.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wednesday 03 November 2004 02:11, Aleksey Gurtovoy wrote:
Matthias Troyer writes:
Could these patches be applied to make program_options compile with the IBM compiler?
Vladimir?
Applied to trunk and branch. Thanks, Matthias!
--- boost/boost/program_options/detail/utf8_codecvt_facet.hpp Wed Jul 21 09:49:15 2004 +++ ../utf8_codecvt_facet.hpp Tue Nov 2 15:05:34 2004 @@ -146,7 +146,11 @@ const char * from, const char * from_end,
Is it possible that in future, you send patches at attachments. Posting them inline can cause line wrapping (like below), and is less reliable. I could not apply your patch automatically (even after unwrapping).
std::size_t max_limit +#if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) + ) const throw(); +#else ) const; +#endif
// Largest possible value do_length(state,from,from_end,1) could return.
Here's wrapped line. - Volodya
On Nov 3, 2004, at 8:16 AM, Vladimir Prus wrote:
On Wednesday 03 November 2004 02:11, Aleksey Gurtovoy wrote:
Is it possible that in future, you send patches at attachments. Posting them inline can cause line wrapping (like below), and is less reliable. I could not apply your patch automatically (even after unwrapping).
I'll do so in the future Matthias
Hi Aleksey Aleksey Gurtovoy wrote:
http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip
Unfortunately neither of the above links works for me at the moment. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber wrote:
Hi Aleksey
Aleksey Gurtovoy wrote:
http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip
Unfortunately neither of the above links works for me at the moment.
Nevermind, I have successfully downloaded the zip a few minutes ago. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Aleksey Gurtovoy wrote:
Updated draft tarballs for the 1.32 release are available from the following locations:
http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip
I've downloaded the zip and successfully built all libraries with the vc-7_1 toolset. When I try the same with MinGW however, build works only partially. .obj files seem to be compiled ok, linking them together to .lib files fails intermittenly. I'm using WinXP SP2, with Dev-C++ 4.9.9.0 (comes with gcc 3.3.1) installed and use the following command line: bjam "-sTOOLS=mingw" "-sMINGW_ROOT_DIRECTORY=C:\Program Files\Dev-Cpp" 1>log.txt 2>error.txt See attached log.txt and error.txt (BTW: Is there any way to redirect both log and error to the same file?). What I find especially disturbing are the "Program: Files\Dev-Cpp\bin\g++: No such file or directory" messages (Note the colon after Program). As mentioned, not all link actions fail. Up to the point where I cancelled the build, the following libraries were linked correctly: libboost_date_time-mgw-1_32.lib libboost_date_time-mgw-d-1_32.lib libboost_date_time-mgw-mt-1_32.lib libboost_date_time-mgw-mt-d-1_32.lib libboost_date_time-mgw-mt-s-1_32.lib libboost_date_time-mgw-mt-sd-1_32.lib libboost_date_time-mgw-s-1_32.lib libboost_date_time-mgw-sd-1_32.lib libboost_filesystem-mgw-d-1_32.lib libboost_filesystem-mgw-mt-d-1_32.lib libboost_filesystem-mgw-mt-sd-1_32.lib libboost_filesystem-mgw-s-1_32.lib libboost_filesystem-mgw-sd-1_32.lib Does anyone else have this behavior? Are there any workarounds? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
bjam "-sTOOLS=mingw" "-sMINGW_ROOT_DIRECTORY=C:\Program Files\Dev-Cpp" 1>log.txt 2>error.txt
See attached log.txt and error.txt (BTW: Is there any way to redirect both log and error to the same file?). What I find especially disturbing are the "Program: Files\Dev-Cpp\bin\g++: No such file or directory" messages (Note the colon after Program).
IIRC, mingw have problems with path names containing space character. It might be good idea to put this info (or warning) in toolset description. B. -- Bronek Kozicki brok@rubikon.pl http://b.kozicki.pl/
Bronek Kozicki writes:
bjam "-sTOOLS=mingw" "-sMINGW_ROOT_DIRECTORY=C:\Program Files\Dev-Cpp" 1>log.txt 2>error.txt
See attached log.txt and error.txt (BTW: Is there any way to redirect both log and error to the same file?). What I find especially disturbing are the "Program: Files\Dev-Cpp\bin\g++: No such file or directory" messages (Note the colon after Program).
IIRC, mingw have problems with path names containing space character. It might be good idea to put this info (or warning) in toolset description.
Bronek, I'd happily apply a patch for the toolset docs if you send me one. -- Aleksey Gurtovoy MetaCommunications Engineering
Bronek Kozicki <b.kozicki <at> gmail.com> writes:
bjam "-sTOOLS=mingw" "-sMINGW_ROOT_DIRECTORY=C:\Program Files\Dev-Cpp" 1>log.txt 2>error.txt
See attached log.txt and error.txt (BTW: Is there any way to redirect both log and error to the same file?). What I find especially disturbing are the "Program: Files\Dev-Cpp\bin\g++: No such file or directory" messages (Note the colon after Program).
IIRC, mingw have problems with path names containing space character.
That's what I first thought as well, but why are a few of the targets correctly linked and others are not? Anyway, as soon as I get home I'll retry with a path without spaces.
It might be good idea to put this info (or warning) in toolset description.
Definitely. Thanks a lot & Regards, Andreas
Andreas Huber wrote:
IIRC, mingw have problems with path names containing space character.
It definitely has. If you install the compiler in a path without spaces, everything works as expected. Aleksey: Is that patch for the toolset docs still needed? If yes, I'd volunteer to prepare one... Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber writes:
IIRC, mingw have problems with path names containing space character.
It definitely has. If you install the compiler in a path without spaces, everything works as expected.
Aleksey: Is that patch for the toolset docs still needed?
Yes.
If yes, I'd volunteer to prepare one...
Please, and thank you! -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Aleksey: Is that patch for the toolset docs still needed?
Yes.
See attachment... Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Aleksey Gurtovoy -
Andreas Huber -
Bronek Kozicki -
Matthias Troyer -
Vladimir Prus