Re: [Boost-build] detecting MS runtime library version

From: Jim Gallagher (jim_at_[hidden])
Date: 2008-08-21 12:06:32

>Hi Jim.
>
>> I believe that each version of MSVC ships with a set of import libs
>> for the runtime and are tied to a specific version of the runtime.
>
>   I think it is likely that each MSVC ships with a new set of MSVC
>related runtime libraries. However, I do not believe that the two are
>necessarily joined at the hip and can not be separated. For instance, we
>do have a project that we build with Visual Studio 9.0 using the
>run-time and MFC that came with Visual Studio 6.0... and it works fine.
>

OK, I've never done that.

>> It may be possible to configure a given version of the toolchain to
>> link against a set of import libs that came with a different
>> version, but that does not seem like an attractive proposition.
>
>   Hmmm, I am not sure what you are suggesting here. That Boost Build
>only allow building programs using MSVC that link to the runtime library
>that comes with that MSVC version? How about linking it to stlport or
>some other custom runtime? I mean, the 'runtime' is just a set of
>libraries, whether static or shared.
>

I'm probably beyond the extent of my knowledge here, but I thought that
the MS C and CPP runtime libs are 'special' because MS supplies both
the OS and compiler, and also because they are registered in the Windows
Side-by-side subsystem.

>> In a different build environment that I support, I simply use the version
>> identifier of cl.exe (as output in the info message when invoked without any
>> options) to identify the runtime lib version. I do not have enough
>> data to say that this is a full-proof method, but it seems to work.
>
>   Ok, I intended on adding checking the cl.exe version like that to the
>msvc toolset soon now that the Boost 1.36 release is finally our and we
>the ban on build tool changes has been lifted. But I do not understand
>what it is exactly you are proposing this information to be used for?
>Do you just want the MSVC toolset to differentiate between the following
>versions: msvc-8.0express & msvc-8.0express-sp1?

In my group, we are typically customizing commercial-off-the-shelf
products using a specific compiler version certified by the vendor.
Service packs are frequently listed in the certification. In my mind,
the biggest concern is that the run time libs match. For example, if
my customization DLL picks up the 8.0 version of msvcrt, and the COTS
product uses 8.0sp1, we will actually have two copies of the runtime
running in the same process, which will likely result in a crash. At
least I think that's what will happen.

It's not that I'm worried about the 8.0sp1 version in particular, it's
just that I thought that build differentiation may need to be more
specific on MS platforms.  We sometimes build the same code with
different MS compilers to use with different COTS products.

>
>> On a different note, are the docs for the Perforce version of Jam
>> still applicable to the Boost version? I'm having trouble getting
>> up the Jam learning curve using the Boost.Build V2 User Manual, so I'm
>> looking for additional docs to help me out. I have been looking though
>> the different config files, like msvc.jam, but I just don't understand
>> enough yet to make intelligent changes.
>
>   Well, Perforce Jam docs are relevant as far as the basic Jam
>functionality goes minus some extensions made to the Jam code i BJam itself.
>
>   It is not relevant in the small build system (Jambase) native Jam
>contains in its distribution and mentions throughout its docs. That part
>is just a small set of predefined rules (see the Jambase included in the
>Jam's source folder) file and is directly replaced by Boost Build.
>
>   Boost Build on the other hand is another set of predefined rules and
>values. If something is unclear about it or its docs - just ask.
>Hopefully we can clear it up here and your input as a 'new user' would
>be much appreciated in updating the docs for Boost Build.
>
>   I've cleaned up the msvc toolset a bit in my local sandbox and will
>commit it in a few days. Maybe that'll help too.
>
>   Hope this helps.
>
>   Best regards,
>     Jurko Gospodnetić
>

Thanks Jurko, if I think of things that may help the docs I will suggest
them.

Regards,
Jim Gallagher