[1.33.0] Release status and updated timeline
The regression tests are starting to look quite a bit better now, and most of the other pre-release activities (inspection report, documentation updates) are going well. There are a few issues we need to resolve before we can wrap up this release: 1. The Serialization lib is failing many of its regression tests. We need to get these under control. 2. PDF generation of BoostBook documentation is failing (problems with FOP) If anyone else has any other pre-release activities that need to get done, please tell me ASAP. I plan to roll prerelease tarballs this weekend, and hope to release within the next two weeks. Doug Gregor 1.33.0 Release Manager
Dear all, I'm considering some last minute name changes for the iostreams library, and would like some feedback. There are two issues: 1. the names of the fundamental components streambuf_facade and stream_facade 2. inconsistent header names (Note: these changes shouldn't affect the regression tests -- unless I botch them) ----------------------- streambuf_facade and stream_facade: Before I settled on "streambuf_facade" and "stream_facade," I tried five or six other pairs of names for these templates. I finally picked the current names because of the analogy with the iterators library. However, the templates are not really facades -- in the GOF sense -- and I'm not sure that the analogy with the iterators library will be very effective in helping users understand these templates. As a result, I'm think of using the less technical-sounding names "generic_streambuf" and "generic_stream." What do people think? ----------------------- inconsistent header names: Until now I've followed the policy that a header should have the same name as the component it contains, if it contains a single component, and a short descriptive name if it contains several related components. For example, the header regex_filter.hpp contains the single component regex_filter, while the header zlib.hpp contains the component zlib_error, zlib_params, zlib_compressor and zlib_decompressor. This policy has resulted in a peculiar mix of names. For instance, boost/iostreams/filter now contains: bzip2.hpp counter.hpp gzip.hpp line_filter.hpp newline.hpp one_step_filter.hpp regex_filter.hpp stdio_filter.hpp symmetric_filter_adapter.hpp test.hpp zlib.hpp As you can see, some contain "_filter" and some don't, and it all depends on whether the header contains more than one component, which can be hard to remember. I'm thinking of renaming the headers that are curently based on component names so that all headers will have short, simple names. E.g., bzip2.hpp counter.hpp gzip.hpp line.hpp newline.hpp one_step.hpp regex.hpp stdio.hpp symmetric.hpp test.hpp zlib.hpp Thoughts? Best Regards, Jonathan
Douglas Gregor wrote:
1. The Serialization lib is failing many of its regression tests. We need to get these under control.
Summary of pending issues related to the seriaization library. Issues I can deal with a) msvc - serialization of exported pointers broke due to a recent change made to better handle some aspects of abstract base classes. b) TRU64 and CW - experiments are on-going in getting compilers instanticiate code not explicitly referenced. Due to the efforts of Rene Rivera, much progress has been made on CW but there is still a way to go. Issues that I can't deal with a) cw- 9_5- darwin - this fails in execution of all DLL versions of the library. b) acc - looks pretty good - but all DLL versions fail c) gcc- 2.95.3- stlport- 4.6.2- linux doesn't seem to have SPIRIT_ROOT set and pointing to a copy of spirit 1.6x. The serialization library and tests are therefore skipped resulting in white space in the table d) gcc (Beman) I presume this is cygwin which doesn't support wide character i/o. If this toolset name were changed to gcc-cygwin, these tests would be skipped and results would show as white space. e) como- 4_3_3- vc7_1 - There is some sort of conflict between the serialization library and the test library. The results in both instantiating code for streams which results in a linkage error. I made an inquiry to Commeau and here is the response I get: "When templates are involved, often you need to do a closure on a library, using the --prelink_objects command line option: como -c blah1.cpp como -c blah2.cpp como --prelink_objects blah1.obj blah2.obj This can be done "directly" as well: como --prelink_objects blah1.cpp blah2.cpp This will leave specific object files as owners of specific instantiations. Therefore, when some libraries have dependencies on other libraries, they may have to be included in the closure request: como --prelink_objects blah1.obj blah2.obj theOtherLibrary.lib That said, in your case your getting an error from a routine in libcomo, or from some similar standard library. If libcomo, has it been built ok, and w/o any errors? Are there any .lib file in your libcomo directory? What does the file 'makeout' contain?" I'm still digesting this. f) RudbekAssociates results show a recent date/time but contain error message which refer to functions that are no longer in the library. I believe that something needs to be refreshed here. g) last time I checked SunOS, DMC and vacpp failed to build the library due to failures in code outside the serialization library. Generally I have marked these compilers as not usable. Robert Ramey
Robert Ramey ha escrito:
b) acc - looks pretty good - but all DLL versions fail
I cannot help much here, but I can confirm that as of June 28, dll tests were working OK on this compiler, and in fact only 14 tests used to fail: http://lists.boost.org/boost/2005/06/29357.php so I guess something has changed later on that breaks this platform.
g) last time I checked SunOS, DMC and vacpp failed to build the library due to failures in code outside the serialization library. Generally I have marked these compilers as not usable.
Toon Knapen and I have beeing doing some offlist research on vacpp these days, and came close to being able to use Boost.Serialization, but finally gave up. I summarize here our findings in case you want to take on the challenge (now or after 1.33) * Currently Boost.Serialization builds in vacpp. * When trying to use it, the linker complains about undefined symbols like this: ld: 0711-317 ERROR: Undefined symbol: boost::serialization::version<boost::serialization::nvp<const unsigned long>
::value
this seems to be related to a defect in the compiler by which it needs static const data to be defined outside their class: http://lists.boost.org/MailArchives/boost/msg30039.php the problem can be remedied by defining BOOST_NO_INCLASS_MEMBER_INITIALIZATION, though I'm not sure this is a safe move (see http://lists.boost.org/boost/2004/07/7289.php). * We locally defined BOOST_NO_INCLASS_MEMBER_INITIALIZATION for vacpp 6.0 (this change hasn't been commited to the CVS) and the aforementioned problems went away, but then other type of undefined symbols appeared: ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_archive_impl::lookup_helper(const boost::serialization::extended_type_info*,boost::shared_ptr<void>&) ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_archive_impl::insert_helper(const boost::serialization::extended_type_info*,boost::shared_ptr<void>&) ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_iserializer::~basic_pointer_iserializer() ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_iserializer::basic_pointer_iserializer(const boost::serialization::extended_type_info&) ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_oserializer::~basic_pointer_oserializer() ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_oserializer::basic_pointer_oserializer(c and here I gave up. I hope this info is of some help in case you decide to work on making Boost.Serialization work for vacpp. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Which version of vacpp are you using? The vacpp 7.0 compiler handles the static const data as you expect it. That should solve the unresolved externals. If you need help with aix or vacpp issues, feel free to contact me. -- Sean Perry Compiler Development IBM Canada Lab (905)-413-6031 (tie 969-6031), fax (905)-413-4839 Joaquín Mª López Muñoz <joaquin@tid.es> To Sent by: boost@lists.boost.org boost-bounces@lis cc ts.boost.org Subject Re: [boost] [1.33.0] [acc] [vacpp] 07/08/2005 03:54 Release status and updated AM timeline Please respond to boost Robert Ramey ha escrito:
b) acc - looks pretty good - but all DLL versions fail
I cannot help much here, but I can confirm that as of June 28, dll tests were working OK on this compiler, and in fact only 14 tests used to fail: http://lists.boost.org/boost/2005/06/29357.php so I guess something has changed later on that breaks this platform.
g) last time I checked SunOS, DMC and vacpp failed to build the library
due
to failures in code outside the serialization library. Generally I have marked these compilers as not usable.
Toon Knapen and I have beeing doing some offlist research on vacpp these days, and came close to being able to use Boost.Serialization, but finally gave up. I summarize here our findings in case you want to take on the challenge (now or after 1.33) * Currently Boost.Serialization builds in vacpp. * When trying to use it, the linker complains about undefined symbols like this: ld: 0711-317 ERROR: Undefined symbol: boost::serialization::version<boost::serialization::nvp<const unsigned long>
::value
this seems to be related to a defect in the compiler by which it needs static const data to be defined outside their class: http://lists.boost.org/MailArchives/boost/msg30039.php the problem can be remedied by defining BOOST_NO_INCLASS_MEMBER_INITIALIZATION, though I'm not sure this is a safe move (see http://lists.boost.org/boost/2004/07/7289.php). * We locally defined BOOST_NO_INCLASS_MEMBER_INITIALIZATION for vacpp 6.0 (this change hasn't been commited to the CVS) and the aforementioned problems went away, but then other type of undefined symbols appeared: ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_archive_impl::lookup_helper(const boost::serialization::extended_type_info*,boost::shared_ptr<void>&) ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_archive_impl::insert_helper(const boost::serialization::extended_type_info*,boost::shared_ptr<void>&) ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_iserializer::~basic_pointer_iserializer() ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_iserializer::basic_pointer_iserializer(const boost::serialization::extended_type_info&) ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_oserializer::~basic_pointer_oserializer() ld: 0711-317 ERROR: Undefined symbol: .boost::archive::detail::basic_pointer_oserializer::basic_pointer_oserializer(c and here I gave up. I hope this info is of some help in case you decide to work on making Boost.Serialization work for vacpp. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Jul 8, 2005, at 12:14 AM, Robert Ramey wrote:
Douglas Gregor wrote:
1. The Serialization lib is failing many of its regression tests. We need to get these under control.
Summary of pending issues related to the seriaization library.
Issues I can deal with
a) msvc - serialization of exported pointers broke due to a recent change made to better handle some aspects of abstract base classes.
Okay.
b) TRU64 and CW - experiments are on-going in getting compilers instanticiate code not explicitly referenced. Due to the efforts of Rene Rivera, much progress has been made on CW but there is still a way to go.
CodeWarrior is higher priority than Tru64 for this release.
Issues that I can't deal with
a) cw- 9_5- darwin - this fails in execution of all DLL versions of the library. b) acc - looks pretty good - but all DLL versions fail
I'll mark these up as an unresearched problem with shared libraries for that compiler.
c) gcc- 2.95.3- stlport- 4.6.2- linux doesn't seem to have SPIRIT_ROOT set and pointing to a copy of spirit 1.6x. The serialization library and tests are therefore skipped resulting in white space in the table
Okay, that's fine.
d) gcc (Beman) I presume this is cygwin which doesn't support wide character i/o. If this toolset name were changed to gcc-cygwin, these tests would be skipped and results would show as white space.
It's not a release platform, so don't worry about it. Only those compilers that show up in the "release view" are important for the release.
e) como- 4_3_3- vc7_1 - There is some sort of conflict between the serialization library and the test library. The results in both instantiating code for streams which results in a linkage error. I made an inquiry to Commeau and here is the response I get:
[snip comeau response] I'm still digesting this.
Again, not a release platform, so don't worry about it.
f) RudbekAssociates results show a recent date/time but contain error message which refer to functions that are no longer in the library. I believe that something needs to be refreshed here.
This is a known issue with incremental testing; send a note to the boost-regression mailing lists asking for RudbekAssociates to clear out the old results for the Serialization lib.
g) last time I checked SunOS, DMC and vacpp failed to build the library due to failures in code outside the serialization library. Generally I have marked these compilers as not usable.
Don't worry about these, either. Doug
"Robert Ramey" <ramey@rrsd.com> wrote in message news:dal243$873$1@sea.gmane.org...
d) gcc (Beman) I presume this is cygwin which doesn't support wide character i/o. If this toolset name were changed to gcc-cygwin, these tests would be skipped and results would show as white space.
We've got the naming problem narrowed down to a particular line of code in regression.py, so hopefully it should be fixed real soon now. --Beman
Douglas Gregor <doug.gregor@gmail.com> writes:
The regression tests are starting to look quite a bit better now, and most of the other pre-release activities (inspection report, documentation updates) are going well. There are a few issues we need to resolve before we can wrap up this release:
1. The Serialization lib is failing many of its regression tests. We need to get these under control. 2. PDF generation of BoostBook documentation is failing (problems with FOP)
If anyone else has any other pre-release activities that need to get done, please tell me ASAP.
Daniel Wallin and I need to finish the parameters library documentation. I am working on it now and I hope we'll have something solid by Monday, but I can't really speak for Daniel's part. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jul 8, 2005, at 12:53 AM, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
The regression tests are starting to look quite a bit better now, and most of the other pre-release activities (inspection report, documentation updates) are going well. There are a few issues we need to resolve before we can wrap up this release:
1. The Serialization lib is failing many of its regression tests. We need to get these under control. 2. PDF generation of BoostBook documentation is failing (problems with FOP)
If anyone else has any other pre-release activities that need to get done, please tell me ASAP.
Daniel Wallin and I need to finish the parameters library documentation. I am working on it now and I hope we'll have something solid by Monday, but I can't really speak for Daniel's part.
Okay. Doug
On Jul 8, 2005, at 8:55 AM, Markus Schöpflin wrote:
Douglas Gregor wrote:
If anyone else has any other pre-release activities that need to get done, please tell me ASAP. I plan to roll prerelease tarballs this weekend, and hope to release within the next two weeks.
Could we add Tru64 to the release view?
I'm sorry, it's too late to make Tru64 a release platform. We should be able to do this for the next release. Doug
Douglas Gregor wrote:
On Jul 8, 2005, at 8:55 AM, Markus Schöpflin wrote:
Douglas Gregor wrote:
If anyone else has any other pre-release activities that need to get done, please tell me ASAP. I plan to roll prerelease tarballs this weekend, and hope to release within the next two weeks.
Could we add Tru64 to the release view?
I'm sorry, it's too late to make Tru64 a release platform. We should be able to do this for the next release.
Will at least the regression results be visible anywhere? Markus
On Jul 8, 2005, at 10:10 AM, Markus Schöpflin wrote:
Douglas Gregor wrote:
On Jul 8, 2005, at 8:55 AM, Markus Schöpflin wrote:
Douglas Gregor wrote:
If anyone else has any other pre-release activities that need to get done, please tell me ASAP. I plan to roll prerelease tarballs this weekend, and hope to release within the next two weeks.
Could we add Tru64 to the release view?
I'm sorry, it's too late to make Tru64 a release platform. We should be able to do this for the next release.
Will at least the regression results be visible anywhere?
They're visible in the "Full View" now, and we'll make them available for the release as well. Doug
participants (8)
-
Beman Dawes -
David Abrahams -
Douglas Gregor -
Joaquín Mª López Muñoz -
Jonathan Turkanis -
Markus Schöpflin -
Robert Ramey -
Sean Perry