[Scons-users] Intermiddent build error on Windows - cl : Command line error D8022 : cannot open 'c:\users\admini~1\appdata\local\temp\tmpekylod.lnk'
Shane Gannon
sgannon200 at gmail.com
Thu Sep 8 09:06:14 EDT 2016
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160908/b96ccc80/attachment-0001.html>
More information about the Scons-users
mailing list