Re: [boost] [1.35.0] Release Candidate 2 available

Is the release mode link error an actual error, or just (un)informative messages being printed by the linker.
Apparently it's not a mere informative message, since the link phase finally ends up in error with a "collect2: ld returned 1 exit status". However, the description of the bug #16276 that originated the bug #16625 says that the issue "may lead to linker failure or corrupted binary", so indeed, it can be what I'm facing. Thanks for the information. Bruno

I am using boost in the build of a commercial software package using Microsoft Visual Studio 2008 as the primary build engine. We are building for both 32- and 64-bit targets. There is no mention in the "getting started" documents of how to build the libraries for different bitnesses. In the VS2008 world the build control files are parameterized with macros, the relevant one of which is $(PlatformName) which has the value "Win32" in 32-bit builds and "x64" in 64-bit builds. To permit maximally "clean" configuration control in the client code tree, the boost libs should live in directories with names based on this convention. I have manually created lib-Win32 and lib-x64 under the prior release and am in the process of doing the same under RC2. The purpose of this note is to suggest that there is probably a large audience of similarly situated folks who could use at least a breadcrumb in the documentation and, perhaps, some automation. The "installer" for windows should, in my opinion, use the ROOT_DIR/lib-$(PlatformName) convention as well.

Stephen Nuchia wrote:
I am using boost in the build of a commercial software package using Microsoft Visual Studio 2008 as the primary build engine. We are building for both 32- and 64-bit targets. There is no mention in the "getting started" documents of how to build the libraries for different bitnesses.
In the VS2008 world the build control files are parameterized with macros, the relevant one of which is $(PlatformName) which has the value "Win32" in 32-bit builds and "x64" in 64-bit builds. To permit maximally "clean" configuration control in the client code tree, the boost libs should live in directories with names based on this convention.
I have manually created lib-Win32 and lib-x64 under the prior release and am in the process of doing the same under RC2. The purpose of this note is to suggest that there is probably a large audience of similarly situated folks who could use at least a breadcrumb in the documentation and, perhaps, some automation. The "installer" for windows should, in my opinion, use the ROOT_DIR/lib-$(PlatformName) convention as well.
Stephen, This sounds like an important issue, but not one we can address in the 1.35.0 time frame. Could you please open a trac ticket for it so it isn't lost? See http://svn.boost.org/trac/boost/newticket Thanks, --Beman
participants (3)
-
Beman Dawes
-
Bruno Lalande
-
Stephen Nuchia