[release][build] Errors compiling 1.68.0 with VS2015 after VS2017

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[release][build] Errors compiling 1.68.0 with VS2015 after VS2017

Boost - Users mailing list
I first used the following to compile Boost 1.68.0 for VS2017:

    cd boost_1_68_0
    bootstrap
    b2 -j8 --build-dir=build toolset=msvc-14.1 variant=debug,release link=shared threading=multi runtime-link=shared address-model=32,64 stage

This appears to have built successfully, although I didn't review the logs.  Afterwards, I tried to build it also for VS2015:

    b2 -j8 --build-dir=build15 toolset=msvc-14.0 variant=debug,release link=shared threading=multi runtime-link=shared address-model=32,64 stage

This build output is full of these errors, however (not specific to Boost.Math, this is just one I happened to capture):

       Creating library build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.lib and object build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.exp
        msvc.manifest.dll build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.dll
        'mt' is not recognized as an internal or external command, operable program or batch file.

            if exist "build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.dll.manifest" (
                call "build15\boost\bin.v2\standalone\msvc\msvc-14.0\msvc-setup.bat" x86 >nul
                mt -nologo -manifest "build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.dll.manifest" "-outputresource:build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.dll;2"
            )

    ...failed msvc.manifest.dll build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.dll build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.lib build15\boost\bin.v2\libs\math\build\msvc-14.0\debug\threading-multi\boost_math_c99l-vc140-mt-gd-x32-1_68.pdb...

Am I missing some incantation?

Oddly when I run a VS2015 Developer Command Prompt it also doesn't know where to find mt.exe.
A VS2017 Developer Command Prompt finds it at C:\Program Files (x86)\Windows Kits\10\bin\10.0.17134.0\x86\mt.exe.
(I'm not having any apparent problems compiling projects within VS2015, but possibly I haven't given it a thorough workout since recently upgrading VS2017.)

On another machine (which only has VS2015 installed), the VS2015 Developer Command Prompt finds it at C:\Program Files (x86)\Windows Kits\8.1\bin\x86\mt.exe.

I do have that same path and file on my PC, but it's not being found for some reason?  Adding it to my PATH before running b2 doesn't help; I assume it's overriding this.

It looks like the VS2015 Developer Prompt is putting C:\Program Files (x86)\Windows Kits\10\bin\x86 into my PATH, which exists but doesn't contain any tools.

I managed to "fix" the VS2015 Developer Prompt by commenting out the line in "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vcvarsqueryregistry.bat" that looks for the Windows 10 SDK.  (Thereby allowing it to find the 8.1 SDK, which contains mt.exe.)

After deleting the build15 directory and adding --reconfigure to the b2 incantation above, this seems to have allowed Boost to compile as well, but I find the whole thing a bit troubling.  Is there a better way to resolve this?

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [release][build] Errors compiling 1.68.0 with VS2015 after VS2017

Boost - Users mailing list
On Fri, 10 Aug 2018 at 07:55, Gavin Lambert via Boost-users <[hidden email]> wrote:
Am I missing some incantation?

I doubt it (reading through your whole post), I've had equally bad experiences with side-by-side installs of VS15 and VS17 and eventually reverted to reinstalling VS17 from scratch as just uninstalling VS15 made the mess even bigger.

degski
--
"If something cannot go on forever, it will stop" - Herbert Stein

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users