[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
Thu Sep 8 11:40:58 EDT 2016 

Shane,

As William said. Going forward (at least the current plan), print() will be
required so both py 2.x and 3.x can be supported by the same SCons codebase.

-Bill

On Thu, Sep 8, 2016 at 6:06 AM, Shane Gannon <sgannon200 at gmail.com> wrote:

> Hi Bill
>
> Actually I made a mistake. Your suggestion
>
> *artifacts = envLocal.SharedLibrary('Library', objFiles)*
>
> does work. Last night I passed the objFiles into a builder for the wrong
> platform. Today, when I noticed the mistake and corrected it, the build
> passed.
>
> I installed the latest development code following the instructions here
>
> https://bitbucket.org/scons/scons
>
> but I got an unusual error
>
>
>     print 'my text output'
>
>               ^
>
> SyntaxError: invalid syntax
>
> Any ideas?
>
> Regards
> Shane
>
> On Thu, Sep 8, 2016 at 12:32 AM, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> Shane,
>>
>>
>> On Wed, Sep 7, 2016 at 12:00 PM, Shane Gannon <sgannon200 at gmail.com>
>> wrote:
>>
>>> Hi Bill
>>>
>>> Your suggestion
>>>
>>> *artifacts = envLocal.SharedLibrary('Library', objFiles)*
>>>
>>> makes complete sense. I switched the script over to this. But it did not
>>> fix the problem.
>>>
>>
>> Had small hope it would.
>> Can you try the latest dev code. There was a bunch of patches to use with
>> open().. as x: syntax which should close files faster.
>>
>>
>>>
>>> Why do this rather than using the created shared librarie?
>>>
>>> In these sections of the code the devs want to access and test internal
>>> functions. i.e. Which are not exposed outside the dll. So they statically
>>> link in the object files rather than the dll.
>>>
>>
>> Could they use a windows .lib (static library?)
>>
>> -Bill
>>
>>
>>>
>>> Regards
>>> Shane
>>>
>>> On Wed, Sep 7, 2016 at 6:53 PM, Bill Deegan <bill at baddogconsulting.com>
>>> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20160908/e5f62951/attachment-0001.html>

More information about the Scons-users mailing list