Re: [boost] Boost build problem

[Emil Dotchevski-3]

Volodya, perhaps you'll find this information helpful in case other
people ask similar questions:

I asked a friend of mine from Microsoft and he indicated that the way
runtime DLLs are located depends on the OS and compiler version, and
that the only way that is guaranteed to work is to install the
redistributables (in case of the release runtime) or the appropriate
version of Visual Studio (or a few other development packages.) He
also recommended not to try to mess with the system "manually" because
it is quite possible to break it beyond repair.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

On Thu, Sep 24, 2009 at 10:24 PM, Vladimir Prus
<vladimir@...> wrote:

> Emil Dotchevski wrote:
>
>> Volodya, thanks for the suggestion again.
>>
>> Using the depends.exe tool from Microsoft I can see that the two
>> missing DLLs my program needs are MSVCP80D.DLL and MSVCR80D.DLL. I'm
>> guessing that Boost Build passes the path specified by <dll-path> in
>> the PATH env variable and that the program itself doesn't look for
>> these particular DLLs on the PATH. Manually adding the directory on
>> the PATH, or even starting the program from the directory containing
>> the DLLs also doesn't work.
>>
>> By now this is well beyond the scope of Boost Build but I'd still want
>> to get it working. Any ideas?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Ian Emmons]

Starting with Visual Studio 2005 (msvc-8), linkage to the run-time  
libraries depends on Microsoft's infrastructure for side-by-side  
execution of different versions of the same DLL.  This is Microsoft's  
attempt to solve the "DLL Hell" problem, in which an executable  
transparently links to the first instance of a DLL found on the path,  
independent of any version dependency.  Clearly, this is a big  
advance, but it comes at the cost of complexity.  As far as I know,  
the only way to deploy the C/C++ run-time is to install the .Net  
framework (which contains the side-by-side execution infrastructure).  
So EXE's and DLL's built with Visual Studio 2005 (msvc-8) require  
the .Net 2.0 run-time, and those built with Visual Studio 2008  
(msvc-9) require .Net 3.5.

On Sep 25, 2009, at 2:00 AM, Emil Dotchevski wrote:

> Volodya, perhaps you'll find this information helpful in case other
> people ask similar questions:
>
> I asked a friend of mine from Microsoft and he indicated that the way
> runtime DLLs are located depends on the OS and compiler version, and
> that the only way that is guaranteed to work is to install the
> redistributables (in case of the release runtime) or the appropriate
> version of Visual Studio (or a few other development packages.) He
> also recommended not to try to mess with the system "manually" because
> it is quite possible to break it beyond repair.
>
> Emil Dotchevski
> Reverge Studios, Inc.
> http://www.revergestudios.com/reblog/index.php?n=ReCode
>
> On Thu, Sep 24, 2009 at 10:24 PM, Vladimir Prus
> <vladimir@...> wrote:
>> Emil Dotchevski wrote:
>>
>>> Volodya, thanks for the suggestion again.
>>>
>>> Using the depends.exe tool from Microsoft I can see that the two
>>> missing DLLs my program needs are MSVCP80D.DLL and MSVCR80D.DLL. I'm
>>> guessing that Boost Build passes the path specified by <dll-path> in
>>> the PATH env variable and that the program itself doesn't look for
>>> these particular DLLs on the PATH. Manually adding the directory on
>>> the PATH, or even starting the program from the directory containing
>>> the DLLs also doesn't work.
>>>
>>> By now this is well beyond the scope of Boost Build but I'd still  
>>> want
>>> to get it working. Any ideas?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Johan Nilsson-4]

Ian Emmons wrote:

> Starting with Visual Studio 2005 (msvc-8), linkage to the run-time
> libraries depends on Microsoft's infrastructure for side-by-side
> execution of different versions of the same DLL.  This is Microsoft's
> attempt to solve the "DLL Hell" problem, in which an executable
> transparently links to the first instance of a DLL found on the path,
> independent of any version dependency.  Clearly, this is a big
> advance, but it comes at the cost of complexity.  As far as I know,
> the only way to deploy the C/C++ run-time is to install the .Net
> framework (which contains the side-by-side execution infrastructure).
> So EXE's and DLL's built with Visual Studio 2005 (msvc-8) require
> the .Net 2.0 run-time, and those built with Visual Studio 2008
> (msvc-9) require .Net 3.5.

AFAIK, .NET runtime is not needed for _native_ C++ applications. Just
installing the runtime using the supplied merge modules (CRT + policy)
should work just fine.

IIRC it is also _possible_ (even though perhaps not officially supported) to
install the needed runtime DLLs in the same directory as the executable with
a specially crafted external manifest.

/ Johan

>
> On Sep 25, 2009, at 2:00 AM, Emil Dotchevski wrote:
>> Volodya, perhaps you'll find this information helpful in case other
>> people ask similar questions:
>>
>> I asked a friend of mine from Microsoft and he indicated that the way
>> runtime DLLs are located depends on the OS and compiler version, and
>> that the only way that is guaranteed to work is to install the
>> redistributables (in case of the release runtime) or the appropriate
>> version of Visual Studio (or a few other development packages.) He
>> also recommended not to try to mess with the system "manually"
>> because it is quite possible to break it beyond repair.
>>
>> Emil Dotchevski
>> Reverge Studios, Inc.
>> http://www.revergestudios.com/reblog/index.php?n=ReCode
>>
>> On Thu, Sep 24, 2009 at 10:24 PM, Vladimir Prus
>> <vladimir@...> wrote:
>>> Emil Dotchevski wrote:
>>>
>>>> Volodya, thanks for the suggestion again.
>>>>
>>>> Using the depends.exe tool from Microsoft I can see that the two
>>>> missing DLLs my program needs are MSVCP80D.DLL and MSVCR80D.DLL.
>>>> I'm guessing that Boost Build passes the path specified by
>>>> <dll-path> in the PATH env variable and that the program itself
>>>> doesn't look for these particular DLLs on the PATH. Manually
>>>> adding the directory on the PATH, or even starting the program
>>>> from the directory containing the DLLs also doesn't work.
>>>>
>>>> By now this is well beyond the scope of Boost Build but I'd still
>>>> want
>>>> to get it working. Any ideas?
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Michael Weber-18]

On Mon, Sep 28, 2009 at 12:41 AM, Johan Nilsson
<r.johan.nilsson@...> wrote:

>
> Ian Emmons wrote:
>>
>> Starting with Visual Studio 2005 (msvc-8), linkage to the run-time
>> libraries depends on Microsoft's infrastructure for side-by-side
>> execution of different versions of the same DLL.  This is Microsoft's
>> attempt to solve the "DLL Hell" problem, in which an executable
>> transparently links to the first instance of a DLL found on the path,
>> independent of any version dependency.  Clearly, this is a big
>> advance, but it comes at the cost of complexity.  As far as I know,
>> the only way to deploy the C/C++ run-time is to install the .Net
>> framework (which contains the side-by-side execution infrastructure).
>> So EXE's and DLL's built with Visual Studio 2005 (msvc-8) require
>> the .Net 2.0 run-time, and those built with Visual Studio 2008
>> (msvc-9) require .Net 3.5.
>
> AFAIK, .NET runtime is not needed for _native_ C++ applications. Just installing the runtime using the supplied merge modules (CRT + policy) should work just fine.
>
> IIRC it is also _possible_ (even though perhaps not officially supported) to install the needed runtime DLLs in the same directory as the executable with a specially crafted external manifest.
>
> / Johan

Installation of .net is not necessary -- Microsoft distributes
installers for the runtime alone. Make sure you find the one specific
to your build tool -- i.e., MSVS2005 / 2008, and with or without the
corresponding SP1.

e.g., here is the installer for MSVS2008 SP1:

http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en

The bottom of that page has links to 2005 runtimes, and runtimes with
/ without MSVS 200x SP1.

Michael
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Matthew Chambers-3]

Michael Weber wrote:

> On Mon, Sep 28, 2009 at 12:41 AM, Johan Nilsson
> <r.johan.nilsson@...> wrote:
>  
>> Ian Emmons wrote:
>>    
>>> Starting with Visual Studio 2005 (msvc-8), linkage to the run-time
>>> libraries depends on Microsoft's infrastructure for side-by-side
>>> execution of different versions of the same DLL.  This is Microsoft's
>>> attempt to solve the "DLL Hell" problem, in which an executable
>>> transparently links to the first instance of a DLL found on the path,
>>> independent of any version dependency.  Clearly, this is a big
>>> advance, but it comes at the cost of complexity.  As far as I know,
>>> the only way to deploy the C/C++ run-time is to install the .Net
>>> framework (which contains the side-by-side execution infrastructure).
>>> So EXE's and DLL's built with Visual Studio 2005 (msvc-8) require
>>> the .Net 2.0 run-time, and those built with Visual Studio 2008
>>> (msvc-9) require .Net 3.5.
>>>      
>> AFAIK, .NET runtime is not needed for _native_ C++ applications. Just installing the runtime using the supplied merge modules (CRT + policy) should work just fine.
>>
>> IIRC it is also _possible_ (even though perhaps not officially supported) to install the needed runtime DLLs in the same directory as the executable with a specially crafted external manifest.
>>
>> / Johan
>>    
>
> Installation of .net is not necessary -- Microsoft distributes
> installers for the runtime alone. Make sure you find the one specific
> to your build tool -- i.e., MSVS2005 / 2008, and with or without the
> corresponding SP1.
>
> e.g., here is the installer for MSVS2008 SP1:
>
> http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en
>
> The bottom of that page has links to 2005 runtimes, and runtimes with
> / without MSVS 200x SP1.
>
> Michael
>  

You can use the latest version of each generation's redistributables to
install all versions of the runtime for that generation. The generations
are 2003, 2005, 2008, 2010. Each generation has several versions, but as
long as you install the latest version it will install all the previous
runtimes for that generation. For 2005 and 2008, the latest version is
SP1. Johan is correct that you can redistribute the runtime DLLs with
your application if you set up the manifest correctly. But if your
application depends on 3rd party binaries that compiled with different
runtime versions, then you all of a sudden have to redistribute that
version too, so it becomes a big mess. But at least if you do it that
way you don't need Administrator privileges to install. :/

-Matt
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build