[1.35.0] Release Candidate 3 available
See http://boost.cowic.de/rc/ For this release candidate the naming is exactly the same as it will be in the final release. Unless a showstopper emerges, these exact files will become the final release. Before declaring the release done, we need to verify that none of the four package files is corrupt and installs without error. I'm starting to do that now. I encourage others to also look for showstoppers, and report results on the developer or user lists. If no showstoppers surface by 9 AM tomorrow morning, US Eastern time, I'll declare 1.35.0 done, create the tag, and push the files out to Sourceforge. --Beman
Beman Dawes wrote:
For this release candidate the naming is exactly the same as it will be in the final release. Unless a showstopper emerges, these exact files will become the final release.
Before declaring the release done, we need to verify that none of the four package files is corrupt and installs without error. I'm starting to do that now. I encourage others to also look for showstoppers, and report results on the developer or user lists.
All four package files downloaded, unpacked, and installed without problems. --Beman
On Fri, 28 Mar 2008 09:37:32 -0400, Beman Dawes wrote:
For this release candidate the naming is exactly the same as it will be in the final release. Unless a showstopper emerges, these exact files will become the final release.
Before declaring the release done, we need to verify that none of the four package files is corrupt and installs without error. I'm starting to do that now. I encourage others to also look for showstoppers, and report results on the developer or user lists.
If no showstoppers surface by 9 AM tomorrow morning, US Eastern time, I'll declare 1.35.0 done, create the tag, and push the files out to Sourceforge.
Everything ran properly using configure && make check on Ubuntu 7.10. Serialization issues: http://svn.boost.org/trac/boost/ticket/1711 http://svn.boost.org/trac/boost/ticket/1725 At least the tests should be updated to show proper workarounds if a new feature doesn't work properly across popular compilers (1711). I am not using the bleeding edge (g++ 4.1 - bleeding is 4.3?). I leave it up to you to decide the showstopping-ness of it all but the tests will fail (and so will code that tries to mimic the tests) on a lot of machines. Robert pinged Dave about the issue but I haven't heard anything more. Besides these two things, for some reason the doc files have the executable bits set on Linux which is strange, but not a real problem. This might be caused by packaging on Windows. Very good release, I think. I especially like the Boost Book documentation :-) -- Sohail Somani http://uint32t.blogspot.com
on Fri Mar 28 2008, Sohail Somani <sohail-Jk4wshXjlOsFFmt/ZbAu/w-AT-public.gmane.org> wrote:
http://svn.boost.org/trac/boost/ticket/1711 http://svn.boost.org/trac/boost/ticket/1725
At least the tests should be updated to show proper workarounds if a new feature doesn't work properly across popular compilers (1711). I am not using the bleeding edge (g++ 4.1 - bleeding is 4.3?).
I leave it up to you to decide the showstopping-ness of it all but the tests will fail (and so will code that tries to mimic the tests) on a lot of machines. Robert pinged Dave about the issue but I haven't heard anything more.
He did? I didn't get any private email about it and haven't been able to keep up with this list for the last few weeks. -- Dave Abrahams Boost Consulting http://boost-consulting.com
On Fri, 28 Mar 2008 16:02:11 -0400, David Abrahams wrote:
on Fri Mar 28 2008, Sohail Somani <sohail-Jk4wshXjlOsFFmt/ZbAu/w-AT-public.gmane.org> wrote:
http://svn.boost.org/trac/boost/ticket/1711 http://svn.boost.org/trac/boost/ticket/1725
At least the tests should be updated to show proper workarounds if a new feature doesn't work properly across popular compilers (1711). I am not using the bleeding edge (g++ 4.1 - bleeding is 4.3?). [snip]
He did? I didn't get any private email about it and haven't been able to keep up with this list for the last few weeks.
I think it was a mailing list ping so it could have gotten lost. Anyway, now it is found! I would appreciate your comments on 1711 if you have some time. I think I am CC'ed on the ticket so if there are tests you want me to try, feel free to add them there. I futzed around a bit to try to determine exactly when the problem happens but didn't figure out why. As for the second (examples not compiling), I think you are correct that it is a Jamfile problem. Not a showstopper by any means. And it seems to be fixed in trunk. -- Sohail Somani http://uint32t.blogspot.com
on Fri Mar 28 2008, Sohail Somani <sohail-Jk4wshXjlOsFFmt/ZbAu/w-AT-public.gmane.org> wrote:
Serialization issues:
http://svn.boost.org/trac/boost/ticket/1711 http://svn.boost.org/trac/boost/ticket/1725
At least the tests should be updated to show proper workarounds if a new feature doesn't work properly across popular compilers (1711). I am not using the bleeding edge (g++ 4.1 - bleeding is 4.3?).
That second problem is surely not a compiler dependency but a failure to write a working Jamfile, is it not? -- Dave Abrahams Boost Consulting http://boost-consulting.com
On Fri, 28 Mar 2008 16:03:28 -0400, David Abrahams wrote:
on Fri Mar 28 2008, Sohail Somani <sohail-Jk4wshXjlOsFFmt/ZbAu/w-AT-public.gmane.org> wrote:
Serialization issues:
http://svn.boost.org/trac/boost/ticket/1711 http://svn.boost.org/trac/boost/ticket/1725
That second problem is surely not a compiler dependency but a failure to write a working Jamfile, is it not?
Yep. Fixed in trunk as far as I can tell. -- Sohail Somani http://uint32t.blogspot.com
Its not really fixed in the trunk. I just reordered the headers in test_exported so it would will still test the rest of it. I want to add a special test for this, put it into the trunk and update the documention to describe the real situation - that is the head order is only remains as an issue for some compilers - currently I believe that that includes gcc 4.1+ (I think). Robert Ramey Sohail Somani wrote:
On Fri, 28 Mar 2008 16:03:28 -0400, David Abrahams wrote:
on Fri Mar 28 2008, Sohail Somani <sohail-Jk4wshXjlOsFFmt/ZbAu/w-AT-public.gmane.org> wrote:
Serialization issues:
http://svn.boost.org/trac/boost/ticket/1711 http://svn.boost.org/trac/boost/ticket/1725
That second problem is surely not a compiler dependency but a failure to write a working Jamfile, is it not?
Yep. Fixed in trunk as far as I can tell.
On Fri, 28 Mar 2008 14:41:37 -0800, Robert Ramey wrote:
I want to add a special test for this, put it into the trunk and update the documention to describe the real situation - that is the head order is only remains as an issue for some compilers - currently I believe that that includes gcc 4.1+ (I think).
I think if the documentation is updated for 1.35 that would be way better than doing nothing. Just took a look at it again... Still can't figure it out! -- Sohail Somani http://uint32t.blogspot.com
On Fri, 28 Mar 2008 14:41:37 -0800, Robert Ramey wrote:
Its not really fixed in the trunk.
I just reordered the headers in test_exported so it would will still test the rest of it.
I want to add a special test for this, put it into the trunk and update the documention to describe the real situation - that is the head order is only remains as an issue for some compilers - currently I believe that that includes gcc 4.1+ (I think).
I think this fixes it: http://svn.boost.org/trac/boost/attachment/ticket/1711/header_ordering_fix.2... I know you use Boost on Visual C++ so if you can try it and let me know if it works, that would be helpful. -- Sohail Somani http://uint32t.blogspot.com
I think this fixes it:
On Sat, 29 Mar 2008 03:05:39 +0000, Sohail Somani wrote: header_ordering_fix.2.patch
I know you use Boost on Visual C++ so if you can try it and let me know if it works, that would be helpful.
I think I lied... But anyway, that patch has the general idea. -- Sohail Somani http://uint32t.blogspot.com
This is a showstopper for me right now, though I am by no means an expert at running bjam. On a Windows (server 2003) 64-bit platform with MSVC 9.0 I am trying to build the major permutations of the library in both 32- and 64-bit variants. I was able to find command lines that appear to do the job for the 32-bit, debug/release, shared/static combinations and for the static combinations in 64-bit mode. I'm getting the following output when I try to build shared libraries for 64-bit, with "shared" or "static" or no specification for link and runtime-link C:\code\Version9\boost>bjam --toolset=msvc msvc/architecture=x86/address-model=64/runtime-link=shared/link=shared debug stage warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. WARNING: No python installation configured and autoconfiguration failed. See http://www.boost.org/libs/python/doc/building.html for configuration instructions or pass --without-python to suppress this message and silently skip all Boost.Python targets Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). Skipping build of: libs/python/build/boost_python <build>no in common properti es Skipping build of: libs/python/build/boost_python <build>no in common properti es C:/code/Version9/boost/tools/build/v2/build\virtual-target.jam:996: in virtual-t arget.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage\lib>boost_date_time-vc90-mt-gd-1 _35.dll error: previous virtual target { common%common.copy-boost_date_time-vc90-mt-gd-1 _35.dll.SHARED_LIB { msvc%msvc.link.dll-boost_date_time-vc90-mt-gd-1_35.dll.SHAR ED_LIB { msvc%msvc.compile.c++-greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.C PP } } { msvc%msvc.compile.c++-date_generators.obj.OBJ { gregorian/date_generato rs.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-boost_date_time-vc90-mt-gd-1_ 35.dll.SHARED_LIB { msvc%msvc.link.dll-boost_date_time-vc90-mt-gd-1_35.dll.SHARE D_LIB { msvc%msvc.compile.c++-greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.CP P } } { msvc%msvc.compile.c++-date_generators.obj.OBJ { gregorian/date_generator s.cpp.CPP } } } } error: created from ./stage-proper error: added properties: none error: removed properties: <address-model>64 <architecture>x86 C:/code/Version9/boost/tools/build/v2/build\virtual-target.jam:453: in actualize -no-scanner from module object(file-target)@2049 C:/code/Version9/boost/tools/build/v2/build\virtual-target.jam:118: in object(fi le-target)@2049.actualize from module object(file-target)@2049 C:/code/Version9/boost/tools/build/v2\build-system.jam:675: in load from module build-system C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import from mod ule modules C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build f rom module C:\code\Version9\boost\boost-build.jam:11: in module scope from module C:\code\Version9\boost> -----Original Message----- From: Beman Dawes [mailto:bdawes@acm.org] Sent: Friday, March 28, 2008 8:38 AM To: Boost mailing list; Boost Users mailing list Subject: [Boost-users] [1.35.0] Release Candidate 3 available See http://boost.cowic.de/rc/ For this release candidate the naming is exactly the same as it will be in the final release. Unless a showstopper emerges, these exact files will become the final release. Before declaring the release done, we need to verify that none of the four package files is corrupt and installs without error. I'm starting to do that now. I encourage others to also look for showstoppers, and report results on the developer or user lists. If no showstoppers surface by 9 AM tomorrow morning, US Eastern time, I'll declare 1.35.0 done, create the tag, and push the files out to Sourceforge. --Beman
Stephen Nuchia wrote:
This is a showstopper for me right now, though I am by no means an expert at running bjam. On a Windows (server 2003) 64-bit platform with MSVC 9.0 I am trying to build the major permutations of the library in both 32- and 64-bit variants. I was able to find command lines that appear to do the job for the 32-bit, debug/release, shared/static combinations and for the static combinations in 64-bit mode.
I'm getting the following output when I try to build shared libraries for 64-bit, with "shared" or "static" or no specification for link and runtime-link
C:\code\Version9\boost>bjam --toolset=msvc msvc/architecture=x86/address-model=64/runtime-link=shared/link=shared .......
C:/code/Version9/boost/tools/build/v2/build\virtual-target.jam:996: in virtual-t arget.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage\lib>boost_date_time-vc90-mt-gd-1 _35.dll error: previous virtual target { common%common.copy-boost_date_time-vc90-mt-gd-1 _35.dll.SHARED_LIB { msvc%msvc.link.dll-boost_date_time-vc90-mt-gd-1_35.dll.SHAR ED_LIB { msvc%msvc.compile.c++-greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.C PP } } { msvc%msvc.compile.c++-date_generators.obj.OBJ { gregorian/date_generato
Please use the following command line: bjam --toolset=msvc architecture=x86 address-model=64 runtime-link=shared link=shared The command line you've specified say: 1. Build with 'msvc' 2. Build also with 'msvc' using address-model=64, etc So, in essence you request two builds. The 64-bitness is presently not represented in library name, or library path. So, you request to create two variants, and place them in the files with the same name. Boost.Build detects this conflict and reports its. You might want to note that 'msvc' is shorthard for toolset=msvc, whereas --toolset=msvc is actually same as 'toolset=msvc'. It's unfortunate that --toolset option exists, and advertised in the getting started docs, but that's not a topic for today. Also note that it would be great if your configure your mail client not to wrap long lines into unreadability :-) - Volodya
Please use the following command line: bjam --toolset=msvc architecture=x86 address-model=64 runtime-link=shared link=shared
This worked much more smoothly; I'm now able to link all of my client code. Thank you for your help! I will repay it in time, as Aesop's mouse did the lion.
The command line you've specified say: 1. Build with 'msvc' 2. Build also with 'msvc' using address-model=64, etc
Browsing the documentation fairly extensively over the course of several days left me with only the faintest idea that the above might be happening and that the syntax you recommend was even possible. You can't put everything into the tutorial, I know, but "the way it thinks" should be more directly described or the description should be more visibly linked. IMHO.
Also note that it would be great if your configure your mail client not to wrap long lines into unreadability :-)
Yes, it would. This is a good news / bad news situation. I'm a Unix / open-source guy stuck in a Windows shop. I hope that will make me a valuable contributor. But configuring Outlook is yet another several days of reading bad documentation that I don't have time for. I'll pay more attention to avoiding the situation manually; the MUA is not showing me what the MTA ends up sending to the list before it goes out. So much for WYSIWYG.
Hello, Compiled and installed the bz2 package, everything worked well for me on a Ubuntu with GCC 4.1.3 (using Bjam directly, not configure & make). Bruno
participants (2)
-
Beman Dawes -
Bruno Lalande -
David Abrahams -
Robert Ramey -
Sohail Somani -
Stephen Nuchia -
Vladimir Prus