[Scons-users] Intermiddent build error on Windows - cl : Command line error D8022 : cannot open 'c:\users\admini~1\appdata\local\temp\tmpekylod.lnk'

Bill Deegan bill at baddogconsulting.com
Wed Sep 7 13:53:45 EDT 2016 

Shane,

Why don't you do this:

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


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


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



*envTest['LIBS'].append(objFiles) # Add the .obj files to the link path on
another environment*
Why do this rather than using the created shared librarie?
The obj files are not libraries...

*Or if you want a static library for windows, create a .lib with those
objects?*


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

*envTest.Program('TestExecutable', test_sources) # Create a test executable
which re-uses the .obj files from LIBS on another environment*
Is the logic above in a second SConscript?

-Bill

On Wed, Sep 7, 2016 at 10:27 AM, Shane Gannon <sgannon200 at gmail.com> wrote:

> One other update. Might explain the *tempfile_cmdlist* issue somewhat.
>
> I've identified a section of the build where, if I disable it, the build
> passes when using the standard 2.5.0 release.
>
> This part of the build does something a little unusual.
>
>
> *sources = getAllSources() # Get all the .cpp files*
>
>
> *objFiles = envLocal.Object(sources) # Create a group of .obj files from
> the sources*
>
>
> *artifacts = envLocal.SharedLibrary('Library', sources) # Create a shared
> library from the sources*
>
> *envTest['LIBS'].append(objFiles) # Add the .obj files to the link path on
> another environment*
>
>
> *test_sources = getAllSources() # Get all the test .cpp files*
>
> *envTest.Program('TestExecutable', test_sources) # Create a test
> executable which re-uses the .obj files from LIBS on another environment*
>
> This might cause issues for the *tempfile_cmdlist* check. But there are 3
> other sections of the build that do the same thing and they're fine.
>
>
> On Wed, Sep 7, 2016 at 4:27 PM, Shane Gannon <sgannon200 at gmail.com> wrote:
>
>> Hi Bill
>>
>> In a local version of SCons 2.5.0 I made the following changes to
>> SCons/Platform/__init__.py
>>
>>         # Check if we already created the temporary file for this target
>>         # It should have been previously done by Action.strfunction() call
>>         #node = target[0] if SCons.Util.is_List(target) else target
>>         #cmdlist = getattr(node.attributes, 'tempfile_cmdlist', None) \
>>         #            if node is not None else None
>>         #if cmdlist is not None :
>>         #    return cmdlist
>> .........
>>         # Store the temporary file command list into the target
>> Node.attributes
>>         # to avoid creating two temporary files one for print and one for
>> execute.
>>         cmdlist = [ cmd[0], prefix + native_tmp + '\n' + rm, native_tmp ]
>>         #if node is not None:
>>         #    try :
>>         #        setattr(node.attributes, 'tempfile_cmdlist', cmdlist)
>>         #    except AttributeError:
>>         #        pass
>>         return cmdlist
>>
>> i.e. I commented out the *tempfile_cmdlist* check.
>>
>> The comments lead me to believe this code is a performance fix. I assumed
>> removing it would not cause breaks.
>>
>> That seems to be the case. SCons did not break. Plus now my build
>> succeeds.
>>
>> I'd guess that SCons is setting this attribute on a node. But that node
>> is being used more than once in our build (really not sure if this is
>> possible). When the node is first used tempfile_cmdlist is created as well
>> as the temp file. But when it is re-used it detects that 'tempfile_cmdlist'
>> already exists and does not bother to create a second temp file.
>>
>> Is that possible? What would make it specific to our build? i.e.
>> Otherwise I assume more people would have reported this problem.
>>
>> Regards
>> Shane
>>
>> On Wed, Sep 7, 2016 at 3:26 PM, Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>>
>>> Shane,
>>>
>>> I didn't see any change in the logic which opens, writes, or closes the
>>> tmp files in those commits.
>>> Only in the way it's used by mslink, and msvc and some messaging and
>>> another test.
>>>
>>> -Bill
>>>
>>> On Wed, Sep 7, 2016 at 6:52 AM, Shane Gannon <sgannon200 at gmail.com>
>>> wrote:
>>>
>>>> Hi William
>>>>
>>>> To be truthful I don't have the expertise to rule out SCon 2.3.4. But
>>>> we have run thousands of builds on it without issue. In constrast on 2.5.0
>>>> (and to a lesser extent 2.3.6 & 2.3.5) we can fully reproduce this problem.
>>>>
>>>> That suggests an edge condition was introduced by 2.3.5. I took a look
>>>> back through the commit history and came across
>>>>
>>>> https://bitbucket.org/scons/scons/commits/bad59be7270dbbe62c
>>>> 7868a532fad84480f95fae
>>>> https://bitbucket.org/scons/scons/commits/9aa37cd21e99eb684a
>>>> b6ae8f7b21e0a71751ac7f
>>>> https://bitbucket.org/scons/scons/commits/da5785c5f30f852734
>>>> b3f985b798a5508bfea9db
>>>>
>>>> which are consequetive commits by the same author (LaurentMarchelli).
>>>> He was working on the SCons/Platform/__init__.py file and the TempFileMunge
>>>> class. This is the class that creates the .lnk files.
>>>>
>>>> Regards
>>>> Shane
>>>>
>>>> On Wed, Sep 7, 2016 at 2:16 PM, William Blevins <wblevins001 at gmail.com>
>>>> wrote:
>>>>
>>>>> Shane,
>>>>>
>>>>> We can look into that specific revision, but if this is a race
>>>>> condition, then it's possible that this is a problem in other versions. It
>>>>> doesn't make much sense that the issue is not reproducible in version 2.4.0
>>>>> unless there was a missing patch that was reapplied (which is unlikely but
>>>>> not impossible).
>>>>>
>>>>> V/R,
>>>>> William
>>>>>
>>>>> On Wed, Sep 7, 2016 at 8:30 AM, Shane Gannon <sgannon200 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I've been testing out some scenarios and here is what I discovered
>>>>>>
>>>>>> SCons 2.5.0 with vs2013 - Reproduced the problem
>>>>>>
>>>>>> SCons 2.3.6 with vs2013 - Reproduced the problem
>>>>>>
>>>>>> SCons 2.3.5 with vs2013 - Reproduced the problem
>>>>>>
>>>>>> SCons 2.5.0 with vs2013 on Windows 7 - Reproduced the problem
>>>>>>
>>>>>> SCons 2.4.0 on both Windows 10 & Window 7 - *Problem not reproduced*
>>>>>>
>>>>>> Seems this bug was introduced by Scons 2.3.5.
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 11:19 AM, Shane Gannon <sgannon200 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> @Bill Deegan
>>>>>>>
>>>>>>> Both the 2013 & 2015 builders use Windows version 10.0.102540 Build
>>>>>>> 10240.
>>>>>>>
>>>>>>> Windows Defender is disabled on the build machines. We took the
>>>>>>> attitude that anti-virus protection was a waste of resources. Plus it
>>>>>>> introduced unwanted variability to build speed.
>>>>>>>
>>>>>>> The Windows Search Indexing Service was enabled. But, after
>>>>>>> disabling it, the problem persisted.
>>>>>>>
>>>>>>> I tested out SCons 2.5.0 with vs2013. It reproduced the problem. So
>>>>>>> this issue may have been introduced since SCons 2.3.4.
>>>>>>>
>>>>>>> @Arvid Rosén
>>>>>>>
>>>>>>> Good suggestion. But we use ActivePython which has pywin32 built
>>>>>>> into it. Verified that with pip list.
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 8:20 AM, Arvid Rosén <arvid at softube.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Do you have pywin32 installed btw?
>>>>>>>>
>>>>>>>> Arvid
>>>>>>>>
>>>>>>>> On 07 Sep 2016, at 01:27, Bill Deegan <bill at baddogconsulting.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Are you also upgrading your version of windows?
>>>>>>>> Do you see the problem with scons 2.5.0 and MSVC 2013?
>>>>>>>>
>>>>>>>> This is not a known issue.
>>>>>>>> However as Arvid said.. it can be related to Windows Defender and
>>>>>>>> Search Indexing.
>>>>>>>> Perhaps you can disable search indexing and see if it has any
>>>>>>>> impact?
>>>>>>>> You might try disabling windows defender for a short test as
>>>>>>>> well... (though I wouldn't advise doing so in an insecure environment or
>>>>>>>> for a long period of time..)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Sep 6, 2016 at 9:59 AM, Shane Gannon <sgannon200 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi all
>>>>>>>>>
>>>>>>>>> I'm in the process of upgrading a Windows build machine. It's tool
>>>>>>>>> set is moving to
>>>>>>>>>
>>>>>>>>>    - 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 getting an unexpected error.
>>>>>>>>>
>>>>>>>>> *cl : Command line error D8022 : cannot open
>>>>>>>>> 'c:\users\admini~1\appdata\local\temp\tmpekylod.lnk'*
>>>>>>>>>
>>>>>>>>> This can occur once or multiple times in the first clean build.
>>>>>>>>> i.e. With each occurence for a different file name. But if I then run a
>>>>>>>>> rebuild the problem resolves itself.
>>>>>>>>>
>>>>>>>>> The .lnk file seems to be SCons specific. It's created in the temp
>>>>>>>>> folder and contains something like
>>>>>>>>>
>>>>>>>>> */nologo /DEBUG /dynamicbase /fixed:no /OPT:REF /OPT:ICF
>>>>>>>>> -ignore:4042 -ignore:4042 -ignore:4099 /nologo /DEBUG /dynamicbase
>>>>>>>>> /fixed:no /OPT:REF /OPT:ICF -ignore:4042 /dll /out:mylibrary.dll .......*
>>>>>>>>>
>>>>>>>>> i.e. The command to execute.
>>>>>>>>>
>>>>>>>>> On Windows *cl* eats this up with
>>>>>>>>>
>>>>>>>>> *cl @c:\users\admini~1\appdata\local\temp\tmpekylod.lnk*
>>>>>>>>>
>>>>>>>>> and executes with the parameters found in the .lnk file.
>>>>>>>>>
>>>>>>>>> AFAIK this behaviour has existed in SCons since version 0.9.
>>>>>>>>>
>>>>>>>>> See
>>>>>>>>>
>>>>>>>>> http://www.scons.org/CHANGES.txt
>>>>>>>>>
>>>>>>>>> *RELEASE 0.90 - Wed, 25 Jun 2003 14:24:52 -0500*
>>>>>>>>>
>>>>>>>>> *  - Use '.lnk' as the suffix on the temporary file for linking long
>>>>>>>>>     command lines (necessary for the Phar Lap linkloc linker).*
>>>>>>>>>
>>>>>>>>> But, for some reason reason, *some* .lnk files are not generated in time for me. Hence the build fails.
>>>>>>>>>
>>>>>>>>> Is this a known issue? Has it been introduced since scons 2.3.4? Is there any work around?
>>>>>>>>>
>>>>>>>>> I should mention that my builder
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    - Is a Windows 10 machine
>>>>>>>>>    - Has 20 cpu cores and runs scons -j 20
>>>>>>>>>    - Has 25Gb of RAM
>>>>>>>>>
>>>>>>>>> There may be a parallization problem here. But it is not an issue for the current build (which also uses -j 20). I experimented with using -j 10 but the problem persisted.
>>>>>>>>>
>>>>>>>>> I also choose to build only a sub-set of the projects. i.e. I excluded the tests. This allowed the build to pass.
>>>>>>>>>
>>>>>>>>> Any thoughts/suggestions?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Shane
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Scons-users mailing list
>>>>>>>>> Scons-users at scons.org
>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-users at scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-users at scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-users at scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-users at scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160907/0d085f31/attachment-0001.html>

More information about the Scons-users mailing list