[1.33.0] Partial thaw on branch for fixing the remaining failures
The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release. Library authors: for any failures that you will not fix, mark them as expected failures on the branch. If you believe there is a configuration problem on one of the test machines, write to the list to say what you think is going on and we'll try to get it fixed. The list of issues we need to fix before we can release is here: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ developer/issues.html Doug
Doug Gregor wrote:
The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release.
Can I stick in some more documentation changes? Jonathan
On Jul 29, 2005, at 3:59 PM, Jonathan Turkanis wrote:
Doug Gregor wrote:
The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release.
Can I stick in some more documentation changes?
Yes, go ahead. Doug
Doug Gregor wrote:
The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release.
Library authors: for any failures that you will not fix, mark them as expected failures on the branch. If you believe there is a configuration problem on one of the test machines, write to the list to say what you think is going on and we'll try to get it fixed. The list of issues we need to fix before we can release is here:
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ developer/issues.html
[Wave] As I've pointed out already the Wave tests on the vc-8_0 platform (gonzalo: http://tinyurl.com/9jsmk) fail for reasons which are completely beyond my comprehension. Bjam tries to link the test executables against a wrong library which doesn't gets built (and which shouldn't get build). This error did not occur during earlier vc-8_0 test runs executed by others. Any ideas? Regards Hartmut
[Wave] As I've pointed out already the Wave tests on the vc-8_0 platform (gonzalo: http://tinyurl.com/9jsmk) fail for reasons which are completely beyond my comprehension. Bjam tries to link the test executables against a wrong library which doesn't gets built (and which shouldn't get build). This error did not occur during earlier vc-8_0 test runs executed by others. Any ideas?
I believe I have an idea what's happening here, in the Jamfile you have: <runtime-link>static <threading>single as build requirements, but vc8 does not have a single threaded runtime at all, and I think it's this that's messing up the build system and the auto linking code, let me try and explain: 1) Setting <runtime-link>static <threading>single causes bjam to mangle the lib name with "-sgd" for the debug build, but it should actually be mangling the name with "-mt-sgd" because there is no single threaded option, so we're really building a multithread lib. 2) Setting <runtime-link>static <threading>single causes bjam to build with /MLd, but that option isn't actually recognised by VC8, so it reverts to the default which appears to be /MT - this is why the auto-link code is trying to link against the "-mt-s" build variant - bjam isn't actually building the variant it thinks it is. If we're serious about VC8 being a release requirement, then we really should fix the build system to handle it correctly, John.
John Maddock wrote:
[Wave] As I've pointed out already the Wave tests on the vc-8_0 platform (gonzalo: http://tinyurl.com/9jsmk) fail for reasons which are completely beyond my comprehension. Bjam tries to link the test executables against a wrong library which doesn't gets built (and which shouldn't get build). This error did not occur during earlier vc-8_0 test runs executed by others. Any ideas?
I believe I have an idea what's happening here, in the Jamfile you have:
<runtime-link>static <threading>single
as build requirements, but vc8 does not have a single threaded runtime at all, and I think it's this that's messing up the build system and the auto linking code, let me try and explain: [snip] If we're serious about VC8 being a release requirement, then we really should fix the build system to handle it correctly,
Attached is a possible fix for tools/build/v1/boost-base.jam that handles the situation. If anyone with vc8 installed can try it that would be nice. As it will take me a while to clean up my hard drive to make room to install vc8 :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Jul 30, 2005, at 10:05 AM, Rene Rivera wrote:
John Maddock wrote:
[Wave] As I've pointed out already the Wave tests on the vc-8_0 platform (gonzalo: http://tinyurl.com/9jsmk) fail for reasons which are completely beyond my comprehension. Bjam tries to link the test executables against a wrong library which doesn't gets built (and which shouldn't get build). This error did not occur during earlier vc-8_0 test runs executed by others. Any ideas?
I believe I have an idea what's happening here, in the Jamfile you have:
<runtime-link>static <threading>single
as build requirements, but vc8 does not have a single threaded runtime at all, and I think it's this that's messing up the build system and the auto linking code, let me try and explain: [snip] If we're serious about VC8 being a release requirement, then we really should fix the build system to handle it correctly,
Attached is a possible fix for tools/build/v1/boost-base.jam that handles the situation. If anyone with vc8 installed can try it that would be nice. As it will take me a while to clean up my hard drive to make room to install vc8 :-\
If someone manages to get this patch tested, please commit to the trunk and RC_1_33_0. Doug
Douglas Gregor wrote:
If someone manages to get this patch tested, please commit to the trunk and RC_1_33_0.
Done. Thanks to John for testing it. And for sparing me the torture of cleaning my Windows drive :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Thanks for fixing this, now the Wave builds finally should proceed on VC8! Regards Hartmut
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Saturday, July 30, 2005 10:58 AM To: boost@lists.boost.org Subject: Re: [boost] [1.33.0] Partial thaw on branch for fixingtheremainingfailures
Douglas Gregor wrote:
If someone manages to get this patch tested, please commit to the trunk and RC_1_33_0.
Done. Thanks to John for testing it. And for sparing me the torture of cleaning my Windows drive :-)
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Problem summary recap: 1) Setting <runtime-link>static <threading>single causes bjam to mangle the lib name with "-sgd" for the debug build, but it should actually be mangling the name with "-mt-sgd" because there is no single threaded option, so we're really building a multithread lib. 2) Setting <runtime-link>static <threading>single causes bjam to build with /MLd, but that option isn't actually recognised by VC8, so it reverts to the default which appears to be /MT - this is why the auto-link code is trying to link against the "-mt-s" build variant - bjam isn't actually building the variant it thinks it is.
If we're serious about VC8 being a release requirement, then we really should fix the build system to handle it correctly,
Attached is a possible fix for tools/build/v1/boost-base.jam that handles the situation. If anyone with vc8 installed can try it that would be nice. As it will take me a while to clean up my hard drive to make room to install vc8 :-\
Unfortunately I don't see the attachment, I've just been testing the fix below, that fixes issue (2) above but not (1), if yours does both then that would be a lot better obviously :-) Thanks, John Index: vc-8_0-tools.jam =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/vc-8_0-tools.jam,v retrieving revision 1.4 diff -r1.4 vc-8_0-tools.jam 31a32,42
# # there is no single threaded runtime in VC-8 anymore, so we redirect requests for # single threaded static builds, to the multithreaded runtime: # flags vc-8_0 CFLAGS <runtime-build>release/<runtime-link>static/<threading>single : /MT ; flags vc-8_0 CFLAGS <runtime-build>debug/<runtime-link>static/<threading>single : /MTd ; # # remove any reference to the single threaded runtime that the base toolset may have added: # CFLAGS = [ difference $(CFLAGS) : /ML ] ; CFLAGS = [ difference $(CFLAGS) : /MLd ] ;
[ok forgot the attachment] -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org Index: tools/build/v1/boost-base.jam =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/boost-base.jam,v retrieving revision 1.152 diff -u -r1.152 boost-base.jam --- tools/build/v1/boost-base.jam 25 Jun 2005 00:29:50 -0000 1.152 +++ tools/build/v1/boost-base.jam 30 Jul 2005 14:59:19 -0000 @@ -2929,6 +2929,11 @@ case vc-8* : requirements += <stlport-iostream>on ; } } + # vc8 doesn't have any single threaded runtime + switch $(toolset) + { + case vc-8* : requirements += <threading>multi ; + } } case intel-win32* : {
On Fri, Jul 29, 2005 at 03:47:10PM -0500, Doug Gregor wrote:
The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release.
hi Doug, i think you may be interested in two trivial bugs i received against the Boost debian packages. bug #308291 [0] fixes a couple of "unused variable" warnings: diff -u /tmp/interface_oarchive.hpp /usr/include/boost/archive/detail/interface_oarchive.hpp --- /tmp/interface_oarchive.hpp 2005-05-09 09:54:24.897652747 +0200 +++ /usr/include/boost/archive/detail/interface_oarchive.hpp 2005-05-09 09:54:56.611522300 +0200 @@ -57,7 +57,7 @@ } template<class T> - const basic_pointer_oserializer * register_type(T * t = NULL){ + const basic_pointer_oserializer * register_type(T * = NULL){ const basic_pointer_oserializer & bpos = instantiate_pointer_oserializer( static_cast<Archive *>(NULL), diff -u /tmp/interface_iarchive.hpp /usr/include/boost/archive/detail/interface_iarchive.hpp --- /tmp/interface_iarchive.hpp 2005-05-09 09:58:24.366913089 +0200 +++ /usr/include/boost/archive/detail/interface_iarchive.hpp 2005-05-09 09:58:31.519755952 +0200 @@ -53,7 +53,7 @@ } template<class T> - const basic_pointer_iserializer * register_type(T * t = NULL){ + const basic_pointer_iserializer * register_type(T * = NULL){ const basic_pointer_iserializer & bpis = archive::detail::instantiate_pointer_iserializer( static_cast<Archive *>(NULL), bug #320677 [1] adds GNU/kFreeBSD to the list of OSes known to Jam: --- boost-1.32.0+1.33.0-cvs20050727.orig/tools/build/v1/allyourbase.jam +++ boost-1.32.0+1.33.0-cvs20050727/tools/build/v1/allyourbase.jam @@ -344,6 +344,9 @@ case IRIX : RANLIB ?= "" ; + + case KFREEBSD : + CLONE ?= cp -fpd ; case LINUX : CLONE ?= cp -fpd ; --- boost-1.32.0+1.33.0-cvs20050727.orig/tools/build/v1/gcc-tools.jam +++ boost-1.32.0+1.33.0-cvs20050727/tools/build/v1/gcc-tools.jam @@ -416,7 +416,7 @@ LNOPT on $(<) = "" ; } # do we use sonames or not? - if $(DLLVERSION) && $(TARGET_TYPE) in $(SHARED_TYPES) && ( $(OS) = LINUX || $(OS) = OPENBSD ) && ! $(NO_GNU_LN) + if $(DLLVERSION) && $(TARGET_TYPE) in $(SHARED_TYPES) && ( $(OS) = LINUX || $(OS) = OPENBSD || $(OS) = KFREEBSD ) && ! $(NO_GNU_LN) { OUTTAG on $(<) = ".$(DLLVERSION)" ; SOTAG on $(<) = ".$(DLLVERSION)" ; @@ -462,7 +462,7 @@ gcc-spawn $(<) ; gcc-Link-action $(<) : $(>) ; - if $(DLLVERSION) && $(TARGET_TYPE) in $(SHARED_TYPES) && ( $(OS) = LINUX || $(OS) = OPENBSD ) && ! $(NO_GNU_LN) + if $(DLLVERSION) && $(TARGET_TYPE) in $(SHARED_TYPES) && ( $(OS) = LINUX || $(OS) = OPENBSD || $(OS) = KFREEBSD ) && ! $(NO_GNU_LN) { return "$(<[1]).$(DLLVERSION)" ; } --- boost-1.32.0+1.33.0-cvs20050727.orig/tools/build/v2/tools/rc.jam +++ boost-1.32.0+1.33.0-cvs20050727/tools/build/v2/tools/rc.jam @@ -28,6 +28,8 @@ create-empty-object $(target) : $(sources[1]) ; case "SOLARIS" : create-empty-object $(target) : $(sources[1]) ; + case "KFREEBSD" : + create-empty-object $(target) : $(sources[1]) ; case "LINUX" : create-empty-object $(target) : $(sources[1]) ; case "*" : --- boost-1.32.0+1.33.0-cvs20050727.orig/tools/build/jam_src/jam.h +++ boost-1.32.0+1.33.0-cvs20050727/tools/build/jam_src/jam.h @@ -385,6 +385,10 @@ # define OS_OPENBSD # define unix # endif +# if defined (__FreeBSD_kernel__) && !defined(__FreeBSD__) +# define OSMINOR "OS=KFREEBSD" +# define OS_KFREEBSD +# endif # ifndef OSMINOR # define OSMINOR "OS=UNKNOWN" # endif --- boost-1.32.0+1.33.0-cvs20050727.orig/tools/build/jam_src/README +++ boost-1.32.0+1.33.0-cvs20050727/tools/build/jam_src/README @@ -87,6 +87,7 @@ SunOS4.1 SUNOS Ultrix 4.2 ULTRIX BeOS BEOS * + GNU/kFreeBSD KFREEBSD * requires editing Makefile please consider to fix them in 1.33.0 release. thank you. cheers domenico [0] http://bugs.debian.org/#308291 [1] http://bugs.debian.org/#320677 -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
On Sun, Jul 31, 2005 at 11:04:04PM +0200, Domenico Andreoli wrote:
...
[0] http://bugs.debian.org/#308291 [1] http://bugs.debian.org/#320677
these should be: [0] http://bugs.debian.org/308291 [1] http://bugs.debian.org/320677 thanks domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
On Jul 31, 2005, at 4:04 PM, Domenico Andreoli wrote:
On Fri, Jul 29, 2005 at 03:47:10PM -0500, Doug Gregor wrote:
The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release.
hi Doug,
i think you may be interested in two trivial bugs i received against the Boost debian packages. [snip] please consider to fix them in 1.33.0 release. thank you.
Unfortunately, we're not going to be able to get these into the release. We will fix them immediately in CVS for the next release. Doug
On Mon, Aug 01, 2005 at 09:32:55AM -0500, Doug Gregor wrote:
On Jul 31, 2005, at 4:04 PM, Domenico Andreoli wrote:
hi Doug,
i think you may be interested in two trivial bugs i received against the Boost debian packages. [snip] please consider to fix them in 1.33.0 release. thank you.
Unfortunately, we're not going to be able to get these into the release. We will fix them immediately in CVS for the next release.
the next release will be fine as well. thanks domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
participants (2)
-
Domenico Andreoli -
Domenico Andreoli -
Doug Gregor -
Douglas Gregor -
Hartmut Kaiser -
John Maddock -
Jonathan Turkanis -
Rene Rivera