0

I'm upgrading Windows build machines to use

  • Visual Studio 2015 Update 3
  • scons 2.5.0
  • msbuild 14.0.25420.1

from

  • Visual Studio 2013 Update 4
  • scons 2.3.4
  • msbuild 12.0.31101

But I'm hitting a build error. During the 'initial' run the build fails due to

cl : Command line error D8022 : cannot open'c:\users\admini~1\appdata\local\temp\tmpjbx8xe.lnk'

There can be several such errors. If I try to find the files I notice that they don't exist.

If I re-run the build it passes.

Has anyone else come across this issue? Is there a solution?

FYI: The build is run in parallel on 20 core machines. Potentially this could cause a timing condition. But it was fine for the previous setup.

Update: After further investigation this looks like it could be a SCons problem. SCons seems to create the .lnk files. It stores the link command line in these files and get cl to execute them via

cl @c:\users\admini~1\appdata\local\temp\tmpjbx8xe.lnk

starian chen-MSFT
  • 33,174
  • 2
  • 29
  • 53
Shane Gannon
  • 6,770
  • 7
  • 41
  • 64
  • You've asked same item in users mailing list. Unlikely to be SCons problem. Please check anti virus and/or search indexer. – bdbaddog Sep 07 '16 at 00:24
  • After posting to StackOverflow I learnt more about the problem. When I found the .lnk files were SCons specific I posted to their users mailer. I'm not sure if this is purely a SCons problem. I'm suspicious of our build (otherwise more people would have reported this). But I have identified the commit to SCons which causes this problem to appear in our build. – Shane Gannon Sep 07 '16 at 15:46

1 Answers1

0

Turns out a edge case bug was introduced by SCons 2.3.5. In the following commits

https://bitbucket.org/scons/scons/commits/bad59be7270dbbe62c7868a532fad84480f95fae https://bitbucket.org/scons/scons/commits/9aa37cd21e99eb684ab6ae8f7b21e0a71751ac7f https://bitbucket.org/scons/scons/commits/da5785c5f30f852734b3f985b798a5508bfea9db

After investigating further I discovered that the failure only occurred in one section of the build scripts. They were doing something like

# Get all the .cpp files
sources = getAllSources() 

# Create a group of .obj files from the sources
objFiles = envLocal.Object(sources) 

# Create a shared library from the sources
artifacts = envLocal.SharedLibrary('Library', sources) 

# Add the .obj files to the link path on another environment
envTest['LIBS'].append(objFiles)

test_sources = getAllSources() # Get all the test .cpp files

# Create a test executable which re-uses the .obj files from LIBS on another environment
envTest.Program('TestExecutable', test_sources)

When I updated the code to be 

# Create a shared library from the objFiles instead of sources
artifacts = envLocal.SharedLibrary('Library', objFiles)

The error disappeared.

Shane Gannon
  • 6,770
  • 7
  • 41
  • 64