I have a problem with linking in VC++ 2010. When I compile in the debug mode it's ok, but in the release mode I regular receive the error "LNK1000: Internal error during IMAGE::BuildImage".
What am I doing wrong?
It began work as soon as I have changed "Whole program optimization" option from "Use Link Time Code Generation" to "Profile Guided Optimization-Instrument".
I encountered the same error. The problem in my case was that I was "playing" with the configuration properties (Project Properties -> Configuration Properties -> General)
The 'Configuration Type' of the project was 'Dynamic Library (.dll)', but the 'Target Extension' was .lib instead of .dll.
April 2020 update
Issue with MSBuild and Docker for Windows was fixed in MSBuild 16.5 (source), so if still seeing that - just update MSVS/MSBuild to the latest version
Original answer
Check for working C compiler: C:/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"C:/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/cl.exe"
is not able to compile a simple test program.
......
LINK : fatal error LNK1000: Internal error during IMAGE::BuildImage.FinalPhase
I was getting this error when I was running cmake in Docker for Windows inside mounted Docker volume. Solution is to copy the workspace to local Docker filesystem.
In vs2019 it works for me：
Project->Property pages->Optimization->Link Time Code Generation, change from "Use Link Time Code Generation" to "Profile Guided Optimization-Instrument"
Related
I'm trying to add Embree to an already working solution, following this resource I've added to my CMakeLists.txt file the following:
FIND_PACKAGE(embree 3.0 REQUIRED)
INCLUDE_DIRECTORIES(${EMBREE_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(application ${EMBREE_LIBRARY})
I've also created a Windows environment variable embree_DIR with my Embree installation folder ("C:\Program Files\Intel\Embree3 x64").
CMake configures the solution fine, but when I build I get a fatal error LNK1104: impossible to open 'embree3.lib'.
Just so you know, I actually have a C:\Program Files\Intel\Embree3 x64\lib\embree3.lib file.
Anyone has any clue why this might be happening?
Set EMBREE_ROOT_DIR e.g.:
set(EMBREE_ROOT_DIR "C:/thirdparty/vs2017/x64/embree-2.17.0")
Link to ${EMBREE_LIBRARIES}
target_link_libraries(YourApp
...
${EMBREE_LIBRARIES}
...
)
I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.
I am trying to compile a simple new project ('hello') for the Arduino M0 Pro. I have created a new project in visual studio 2015 (using vMicro).
But I get the error:
hello.ino: In file included from
arduino.h: 48:17: fatal error: sam.h: No such file or directory
#include "sam.h"
compilation terminated
Through the Arduino IDE - board manager I have installed the cores for Arduino SAM Boards and SAMD Boards. Currently it is on Arduino IDE: v1.6.18, SAM: v1.6.11 and SAMD: v1.6.15 (the newest version at time of writing).
The strange thing is that I do see that the project has included this file, as it is shown in the file tree of External Dependencies, see screenshot.
file tree showing sam.h
I have also checked the include paths in the 'hello.vcxproj' file. I have cut out the list below:
<AdditionalIncludeDirectories>
$(ProjectDir)..\..\..\..\..\Program Files (x86)\Arduino\libraries
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\1.6.10\libraries
$(ProjectDir)..\libraries
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\1.6.10\cores\arduino
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\1.6.10\cores\arduino\avr
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\1.6.10\cores\arduino\USB
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\1.6.10\variants\arduino_mzero
$(ProjectDir)..\hello
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0\CMSIS\Include\
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS-Atmel\1.0.0\CMSIS\Device\ATMEL\
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\c++\4.8.3
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\c++\4.8.3\arm-none-eabi
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\c++\4.8.3\bits
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\sys
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\1.6.10\system
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\avr
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\hardware\samd\usb
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\lib\gcc\arm-none-eabi\4.8.3\include
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0\Device\ATMEL\samd21\include
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0\CMSIS\include
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0\Device\ATMEL\samd21\include\component
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0\Device\ATMEL\samd21\include\instance
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0\Device\ATMEL\samd21\include\pio
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\4.5.0\Device\ATMEL\samd21\include\component
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS-Atmel\1.0.0\CMSIS\Device\ATMEL\samd21\include
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\CMSIS\include
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\CMSIS-Atmel\1.0.0\CMSIS\Device\ATMEL\samd21\include\component
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\CMSIS-Atmel\1.0.0\CMSIS\Device\ATMEL\samd21\include\instance
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\CMSIS-Atmel\1.0.0\CMSIS\Device\ATMEL\samd21\include\pio
$(ProjectDir)..\..\..\AppData\Local\arduino15\packages\arduino\tools\CMSIS\CMSIS-Atmel\1.0.0\CMSIS\Device\ATMEL\samd21\include\component
%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
Even when I just open a completely new project in the Arduino IDE and try to compile it for Arduino M0, I get the exact same error!
I am stuck at this point. I've tried, as suggested at some other websites, de-installing SAM, de-installing SAMD, changing versions of either, but no luck.
In my case the specific solution was to delete the C:\Users[username]\AppData\Local\Arduino15 folder and reinstall the board packages I needed through the Arduino IDE Boards Manager.
Note this will not impact any libraries or other changes you have made in the IDE.
I have a UWP app that compiles successfully if I have UseDotNetNativeToolchain off. But when I turn it on, it gives me the cryptic error:
Internal compiler error: Object reference not set to
an instance of an object. UWPApp C:\Program Files
(x86)\MSBuild\Microsoft.NetNative\x86\ilc\IlcInternals.targets 887 Build
This is all it gives me. What could be causing this? How can I drill down on this.
Using VS2015
Here is the full build output in case that helps:
https://gist.github.com/shannah/e24fe8456313fb9ad98577c9a812f357
The solution to this problem was to disable optimization in a few assemblies I was using in the Default.rd.xml file. E.g.
<Assembly Name="IKVM.OpenJDK.Core" Dynamic="All" DoNotInline="true" DoNotOptimize="true"/>
So I downloaded and installed Microsoft Accelerator v2 to use ParallelArrays. I have referenced it in my project but when I try and execute the code from the module in a script file I get:
"The namespace 'ParallelArrays' is not defined
I have followed the instructions on this post:
Microsoft Accelerator library with Visual Studio F#
I've added a reference to the managed version "Microsoft.Accelerator.dll" to my F# project and then added the native "Accelerator.dll" as an item in my solution and set it's 'Copy To Output Directory' to Copy Always.
Still getting the FSI error and inline error in my script file on the '#load ...' line, however the solution builds fine, and no error in the module file.
Any ideas on what I'm missing? I'm sure it's something stupid.
Thanks,
Justin
UPDATE
I tried mydogisbox's advice, which got rid of the error above, but now when I run the code in the .fsx file I get this error instead:
--> Referenced 'F:\Work\GitHub\qf-sharp\qf-sharp\bin\Debug\Microsoft.Accelerator.dll' (file may be locked by F# Interactive process)
[Loading F:\Work\GitHub\qf-sharp\qf-sharp\MonteCarloGPU.fs]
error FS0192: internal error: F:\Work\GitHub\qf-sharp\qf-sharp\Accelerator.dll: bad cli header, rva 0
UPDATE 2
So the bad header error has dissapeared, but now I get this instead:
Microsoft.ParallelArrays.AcceleratorException: Failure to create a DirectX 9 device.
at Microsoft.ParallelArrays.ParallelArrays.ThrowNativeAcceleratorException()
at Microsoft.ParallelArrays.DX9Target..ctor()
at <StartupCode$FSI_0002>.$FSI_0002_MonteCarloGPU.main#() in F:\Work\GitHub\qf- sharp\qf-sharp\MonteCarloGPU.fs:line 14
Stopped due to error
I found this thread on MSDN however the answers proposed as fixes on that thread barely even relate to the question.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/98600646-0345-4f62-a6c5-f03ac9c77179/ms-accelerator?forum=csharpgeneral
My Direct X version is 11, and I imagine that will suffice, however I tried installing DX9 however, it tells me that a newer version is detected therefore cant install.
There are special directives for referencing dlls from fsi. The #load directive loads the .fs file only. You need to use the #r directive to reference the file. You can either use the full path of the file or you can use #I to include the path to the file. More details here. Keep in mind that fsi is completely independent of your project, so all references in your project must be duplicated in fsi for it to access the same types.