VC9 with amd64 target - wrong LIBPATH for Platform SDK

[bdbaddog]

This issue was originally created at: 2010-07-16 05:24:16. This issue was reported by: carstenf. carstenf said at 2010-07-16 05:24:16

Using SCons 2.0.0.final.0 with VC9 (full) and 64-bit "amd64" target fails in the linking step, because the LIBPATH for the Platform SDK is incomplete.

Please see http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2633741 for details. [dead link]

gregnoel said at 2010-07-21 17:32:07

Bug party triage.

carstenf said at 2010-07-28 15:19:30

Just another small detail: I just added a very simple workaround to my SConstruct files:

if envCommon["TARGET_ARCH"] in ["x86_64", "amd64", "emt64"]:
    envCommon["ENV"]["LIB"] = envCommon["ENV"]["LIB"].replace(
        "C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0\\lib;",
        "C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0\\lib\\x64;",
    )
    envCommon["ENV"]["LIBPATH"] = envCommon["ENV"]["LIBPATH"].replace(
        "C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0\\lib;",
        "C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0\\lib\\x64;",
    )

and it turns out that the LIB makes the difference, not the LIBPATH.

austin_bingham said at 2011-01-04 05:04:18

This bug recently bit me, and I worked up a patch to Tool/MSCommon/sdk.py that I thought I'd pass along. I don't know if it's an entirely correct fix, but maybe it'll help someone. The main issue seems to be that the lib_subdir member of the various WindowsSDK objects is not being used to set up the LIB variable (as noted by Carsten.) I'll attach the patch.

austin_bingham said at 2011-01-04 05:04:46

Created an attachment (id=826) Possible fix for this defect.

garyo said at 2012-09-01 10:01:49

Bumping all old issues targeted for past releases to 2.x.

More information about this issue is at http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2633741. [dead link]

Votes for this issue: 1.

austin_bingham attached scons_ms_sdk.patch at 2011-01-04 05:04:46.

Possible fix for this defect.

[mwichmann]

@jcbrill since this never ends...

[jcbrill]

@mwichmann I'm onboard with trying to close out as many MSVC issues as possible...

[mwichmann]

I've been trying to tag them over the past few months, just found a few more today. https://github.com/SCons/scons/labels/MSVC

[jcbrill]

This issue exists in the current code base. Any target other than x86 should fail.

Reproducible on 64-bit windows with:

env = Environment(MSVC_VERSION = '9.0', MSSDK_VERSION = '7.0',  tools = ['mslink','msvc','mssdk'])

As I've never requested a specific SDK version, this ought to be ... fun?

[bdbaddog]

Ugh the diff in the attached patch is backwards.. (changing to current code instead of from)

Also looks wrong. I'd think the following

263c263
< def set_sdk_by_directory(env, sdk_dir, lib_subdirs):
---
> def set_sdk_by_directory(env, sdk_dir):
282,283c282
<         env_tuple_list.append(('LIB', os.path.join(sdk_dir, lsd))
---
>         env_tuple_list.append(('LIB', os.path.join(sdk_dir, 'lib')))
378,379c377
<     
<     set_sdk_by_directory(env, sdk_dir, mssdk.lib_subdir[env['TARGET_ARCH']])
---
>     set_sdk_by_directory(env, sdk_dir)

Use TARGET_ARCH instead of HOST_ARCH?

[jcbrill]

I'm pretty sure that TARGET_ARCH could be undefined. I think it will need something similar (or the actual call) to get_host_target in vc.py. Thinking out loud as I haven't started investigating in earnest.

[bdbaddog]

I'm pretty sure that TARGET_ARCH could be undefined. I think it will need something similar (or the actual call) to get_host_target in vc.py. Thinking out loud as I haven't started investigating in earnest.

Good point. We probably really need a function in MSCommon to "do the right thing", require TARGET_ARCH if specified, if not specified check HOST_ARCH, and then try acceptable alternatives. Which for LIB might be ok with just adding those in order of preference? Is there any harm in specifying the "wrong" arch in path if it's after the "right" arch? (hmm. not sure the above is clear, please ask for clarification if not?)

[jcbrill]

I need to look to see if there are any order dependencies: vc before sdk or vice-versa. The vc code should set the TARGET_ARCH if it was undefined. As long as the SDK selection takes place after the vc code there would not be a problem. Keep in mind the vc code is testing a list of possible host/target combinations.

The sdk paths are prepended to the environment as they need to override the default msvc/SDK paths from the vcvars file. That is effectively the issue above. The libraries for x86 appear at the front of the search path (LIB) so there are linker errors.

[jcbrill]

The tool order matters.

The first environment:

env = Environment(MSVC_VERSION =  '9.0', MSSDK_VERSION = '7.0', tools = ['mslink', 'msvc', 'mssdk'])

produces different results from the second environment:

env = Environment(MSVC_VERSION =  '9.0', MSSDK_VERSION = '7.0', tools = ['mssdk', 'mslink', 'msvc'])

The first fails as the incorrect lib path is prepended before the msvc tool paths (manually split the paths from env dump for illustration):

'LIB': 'C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0\\lib;'
       'C:\\Users\\test\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\VC\\Lib\\amd64;'
       'C:\\Users\\test\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\WinSDK\\Lib\\x64'

The second succeeds (basically ignoring the SDK request) as the msvc tool paths are prepended before the SDK paths (manually split the paths from env dump for illustration):

'LIB': 'C:\\Users\\test\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\VC\\Lib\\amd64;'
       'C:\\Users\\test\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\WinSDK\\Lib\\x64;'
       'C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0\\lib'

The SDK cache also needs to include the target. This could get a little tricky when the SDK is called first as the host/target combinations have not been evaluated (especially when choosing a default a TARGET_ARCH which may fall back to x86) as the vc code is evaluating that the batch file exists before setting the target.