Force SCons to use 32-bit MSVC compiler on 64-bit Windows

Question

I am trying use cl from Visual Studio 2010 to build the 32-bit version of Mixxx. Mixxx uses SCons to build. My computer is Windows 7 64-bit with too many versions of Visual Studio installed.

Following these instructions, I have tried all sorts of combinations and variations of setenv and vsvars but no matter what I do, I end up on the command line in this situation:

> cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

OK, so cl is pointing to "version 16, x86" - great.

> scons toolchain=msvs force32=1 winlib=%cd%\winlib\x86 sqlitedll=0 staticlibs=1 asmlib=0

[... bunch of output truncated, until we start using the compiler ...]

cl /Fores\qrc_mixxx.obj /c res\qrc_mixxx.cc /TP /Zc:wchar_t- /GL /MP /fp:fast /G
[truncated]
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

(Note - I hacked SCons to remove the /nologo) What? How does cl now mean "version 18, x64"? Did it change my environment? Let's find out:

Terminate batch job (Y/N)? y

>cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

So cl still means "version 16, x86" to the terminal. But SCons always uses "latest version, x64".

(Based on my understanding of the Windows shell, this should not even be possible. I killed the script, so it didn't do any cleanup. How can the meaning of cl change like that?)

I've found a couple hints:

• http://scons.1086193.n5.nabble.com/Using-32-bit-MSVC-compiler-on-64-bit-Windows-td28062.html
• http://www.scons.org/wiki/MsvsMultipleVersions
• Forcing scons to use older compiler?

Based on this, I've added

Environment(MSVC_VERSION = '10.0')
Environment(TARGET_ARCH = 'x86')
print 'hello world'

to the SConstruct. I don't know SCons, and the build scripts are non-trivial, so it's likely that I'm doing this wrong. Regardless, SCons still always uses "newest version, x64".

Cutler

Have you already tried to contact the maintainers of the Mixxx project about this problem? They'll probably be able to help best in this case... – Jauch

Yes, I posted to the mailing list here. I suppose I should have already included this link. – Cutler

Try to follow the instructions at comments.gmane.org/gmane.comp.programming.tools.scons.user/… to enable debugging for the MSVS initialization process. If the additional debug messages don't tell you anything, please post your problem and the debug output to the SCons user ML ([email protected]). – Jauch

Thanks so much, that debugging tip was just what I needed! – Cutler

Answer 1

I turned on logging per dirkbaechle's comment (set SCONS_MSCOMMON_DEBUG=-). This was very helpful. When I added Environment(MSVC_VERSION='10.0') to SConstruct, I could see in the output

get_default_version(): msvc_version:10.0 msvs_version:None
msvc_setup_env: using specified MSVC version '10.0'

[ ... truncated ... ]

get_default_version()
get_default_version(): msvc_version:None msvs_version:None
installed_vcs:['12.0', '10.0', '10.0Exp', '9.0']
msvc_setup_env: using default installed MSVC version '12.0'

Oops - by the time we call get_default_version for the 2nd time, it seems we are using a different environment. I don't understand the Mixxx build scripts well enough to know why, but I'm pretty sure that is the reason.

The Easy Workaround

For people like me who are too lazy to fix their build scripts, there's an easy (but ugly) way to force SCons to do what you want. You just need to intentionally break your newer versions (temporarily, of course). For example, I want to use 2010, x86. First, I rename all the "VC" directories of higher versions.

• C:\Program Files (x86)\Microsoft Visual Studio 12.0\ VC rename to _DISABLED_VC
• C:\Program Files (x86)\Microsoft Visual Studio 11.0\ VC rename to _DISABLED_VC

And now SCons will use 2010 (aka "Microsoft Visual Studio 10.0"), because all higher versions are unavailable. Selecting the target architecture is similar.

• C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\ amd64 rename to _DISABLED_amd64
• do the same for ia64, x86_amd64, x86_ia64, etc.

Cutler

Better to use the TARGET_ARCH variable in your Environment initialization as below. What you've done in "The Easy Workaround" will likely break those visual studio installs.. – Idiotic

@Idiotic - Yes, this answer suggests a workaround that absolutely will break those visual studio installs. But it's easier than trying to fix multi-thousand line build scripts when you don't know scons. – Cutler

that's why you should go to the project support resources if you're stuck.. We're more than willing to help. Either here, IRC, or the Users mailing list. – Idiotic

Answer 2

The Environment kwargs you posted work for me (Scons 2.3.4):

env = Environment(
    MSVC_VERSION='12.0',
    TARGET_ARCH='x86')

env.Program('src.cpp')

The value for a 64-bit program should be TARGET_ARCH='x86_64' according to http://scons.1086193.n5.nabble.com/32-and-64-bit-builds-on-MSVC-td25425.html. Other values of MSVC_VERSION also work.

Rafaellle

Answer 3

I tried setting TARGET_ARCH using env = Environment(blabla), but it didn't help

So I searched for 'TARGET_ARCH' in Scons directory (...\PythonDir\scons-3.0.1\Scons). In my case it was in Environment.py file that has a section with default values. I changed None to 'x86'

# Now set defaults for TARGET_{OS|ARCH}
...
# self._dict['TARGET_ARCH']    = self._dict.get('TARGET_ARCH',None)
self._dict['TARGET_ARCH']    = self._dict.get('TARGET_ARCH','x86')

Then I removed previously compiled Environment.pyc, causing it to be regenerated

And it worked!

Pair

Did you then use env.Program() or did you use Program()? TARGET_ARCH needs to be set when msvc tool is initialized. PLEASE DON"T MODIFY SCONS SOURCES and suggest others do this too. There's an IRC channel, users mailing list and stackoverflow which members of the project monitor. – Idiotic

@Idiotic The OP's desire is to get a required tool compiled (Mixxx), and he barely wants to know what scons is and how to deal with it. My problem was alsmost the same, I tried to compile NSIS. That's why installed scons. I cannot say whether I used env.Program() or Program(), because it's not my sources (however there're several occurencies of env.Program() in SConscript files. Adding env = Environment(TARGET_ARCH='x86') before them didn't help. This solution does work. If you need scons for something else, just revert the changes. – Pair

I understand the situation. Sometimes getting support from projects for issues with their usage of SCons is problematic. Regardless, hacking the source may resolve your issue, but in general it is not a good solution. The better solution would be for enough information to be provided to the SCons developers who can then fix it properly and/or feed a proper fix to the project in question. – Idiotic