[Boost-build] Problem with .rc files and the msvc tool set

Subject: [Boost-build] Problem with .rc files and the msvc tool set
From: Ian Emmons (iemmons_at_[hidden])
Date: 2009-03-01 21:03:14

I am trying to create an exe target that compiles for both Windows and  
Macintosh, and on Windows I want this to have a version resource.  The  
standard way to do this (include the .rc file in the list of sources)  
is failing for me on Macintosh (see my post from earlier today), so  
I'm trying to include the .rc file via a conditional <source>  
feature.  Unfortunately, this is failing for me on Windows.

I have created a simple test case (three files, Jamroot,  
HelloWorld.cpp, and Version.rc, all in a single directory) to  
demonstrate this problem.  Note the library listed in the exe target's  
list of sources in Jamroot, "/site-config//BerkeleyDB".  This is just  
a pre-built library I happened to have already declared in my site- 
config.  The exe source doesn't reference it at all, and I suspect  
that any such library can be substituted with equivalent results.   
However, without the library, the problem goes away.  (More on this  
below.)

The problem only shows when I do a 64-bit build.  Here is the bjam  
command line I'm using  (bjam output shown below):

     bjam -q msvc-9.0 address-model=64 variant=release

This problem only manifests when Boost.Build puts the result of  
compiling the .rc file (Version_res.obj) first in the list of .obj  
files passed to the linker in the .rsp file.  If the .rc file is put  
in the sources list of the exe target or the library dependency is  
removed, then Boost.Build puts Version_res.obj lower in the list, and  
the link succeeds.  But in the configurations shown below,  
Version_res.obj is first, and the link fails.

I can also manually edit the .rsp file, removing the library and  
changing the order of the .obj files.  When I manually issue the same  
link command that bjam does, that link will fail when Version_res.obj  
is first and succeed when it is not.  This proves that the library  
isn't an essential part of the problem, and that it's only  
contribution is to cause Boost.Build to place Version_res.obj first in  
the list of .obj files.

I'm using bjam 3.1.17 and the version of boost.build from boost 1.38.0.

Thanks,

Ian

==========  Jamroot  ==========

project /HW
    :  build-dir ./bin
    ;

exe hwFailsForMSVC
    :  [ glob *.cpp ]
       /site-config//BerkeleyDB
    :  <toolset>msvc:<source>Version.rc
    :  # default build
    :  # usage requirements
    ;

==========  HelloWorld.cpp  ==========

#include <iostream>

using namespace ::std;

int main()
{
   cout << "Hello World!" << endl;
   return EXIT_SUCCESS;
}

==========  Version.rc  ==========

#include <winver.h>

// Note that these two version numbers must match:
#define HW_VERSION_NUMERIC  2, 6, 0, 0
#define HW_VERSION_STRING   "2.6.0.0"

#if !defined(NDEBUG)
#  define HW_FILEFLAGS VS_FF_DEBUG | VS_FF_PRERELEASE |  
VS_FF_PRIVATEBUILD
#  define HW_PRIVATEBUILD "This file is a debug build, and is not  
intended for general distribution."
#else
#  define HW_FILEFLAGS 0x0L
#  define HW_PRIVATEBUILD ""
#endif

VS_VERSION_INFO VERSIONINFO
   FILEVERSION    HW_VERSION_NUMERIC
   PRODUCTVERSION HW_VERSION_NUMERIC
   FILEFLAGSMASK  VS_FFI_FILEFLAGSMASK
   FILEFLAGS      HW_FILEFLAGS
   FILEOS         VOS_NT
   FILETYPE       VFT_DLL
   FILESUBTYPE    VFT2_UNKNOWN
BEGIN
   BLOCK "StringFileInfo"
   BEGIN
      BLOCK "040904b0"
      BEGIN
         VALUE "CompanyName",      "BBN Technologies"
         VALUE "FileDescription",  "Hello World Test Case for  
Boost.Build"
         VALUE "FileVersion",      HW_VERSION_STRING
         VALUE "InternalName",     "HelloWorld"
         VALUE "LegalCopyright",   "Copyright © 2009 by BBN  
Technologies.  All rights reserved."
         VALUE "LegalTrademarks",  "BBNÆ is a registered trademark of  
BBN Technologies."
         VALUE "OriginalFilename", "hw.exe"
#if !defined(NDEBUG)
         VALUE "PrivateBuild",     HW_PRIVATEBUILD
#endif
         VALUE "ProductName",      "HelloWorld"
         VALUE "ProductVersion",   HW_VERSION_STRING
      END
   END
   BLOCK "VarFileInfo"
   BEGIN
      VALUE "Translation", 0x409, 1200
   END
END

==========  bjam output  ==========
...found 15 targets...
...updating 3 targets...
msvc.compile.rc bin\msvc-9.0\release\address-model-64\threading-multi 
\Version_res.obj
Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
Copyright (C) Microsoft Corporation.  All rights reserved.

compile-c-c++ bin\msvc-9.0\release\address-model-64\threading-multi 
\HelloWorld.obj
HelloWorld.cpp
msvc.link bin\msvc-9.0\release\address-model-64\threading-multi 
\hwFailsForMSVC.exe
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
bin\msvc-9.0\release\address-model-64\threading-multi\HelloWorld.obj :  
fatal error LNK1112: module machine type 'x64' conflicts with target  
machine type 'X86'

         call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC 
\vcvarsall.bat" x86_amd64 >nul
link /NOLOGO /INCREMENTAL:NO /subsystem:console /out:"bin 
\msvc-9.0\release\address-model-64\threading-multi 
\hwFailsForMSVC.exe" /LIBPATH:"D:\dev\KB\lib\bdb\msvc-9.0\64"  @"bin 
\msvc-9.0\release\address-model-64\threading-multi 
\hwFailsForMSVC.exe.rsp"
         if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%

...failed msvc.link bin\msvc-9.0\release\address-model-64\threading- 
multi\hwFailsForMSVC.exe...
...failed updating 1 target...
...updated 2 targets...