I am trying to compile an interpreter for the J programming language called "unbox" which can be found at: https://github.com/iocane/unbox
It uses the tup build-system and the github instructions specify to use the tup command from the Visual Studio tools prompt. I downloaded Visual Studio 2015 Community but it doesn't come with the exact prompt mentioned in the instructions so I used the VS2015 x86 x64 Cross Tools Command Prompt. After installing tup and adding it to my path, I navigated to the directory where I cloned "unbox" and typed tup.
However, this is where the problems start, after typing tup I get the following:
* 1) CC src/libj\a.c
a.c
*** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
*** Command ID=663 ran successfully, but tup failed to save the dependencies.
* 2) CC src/libj\af.c
af.c
*** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
*** Command ID=667 ran successfully, but tup failed to save the dependencies.
* 3) CC src/libj\ai.c
ai.c
*** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
*** Command ID=669 ran successfully, but tup failed to save the dependencies.
* 4) CC src/libj\ab.c
ab.c
*** tup errors ***
tup error: File 'C:\Users\I\AppData\Local\Microsoft\VSCommon\14.0\SQM\VCToolsTelemetry.dat' was written to, but is not in .tup/db. You probably should specify it as an output
*** Command ID=665 ran successfully, but tup failed to save the dependencies.
[ ETA~=30s Remaining=130 Active=0 ] 2%
*** tup: 4 jobs failed.
As you can see, the file VCToolsTelemetry.dat was not specified in tup's database.
Does anybody know a way to prevent Visual Studio from using VSToolsTelemetry.dat at all? Or should I contact the unbox developer and have him add that file to the db?
Any help is much appreciated.
The solution was given by Christian Fillion in this comment.
This Microsoft page explains what that file is for and how to prevent Visual Studio tools from writing to it:
By default, the Visual Studio installation enables customer feedback. You can configure Visual Studio to disable customer feedback on individual computers by changing the value of the following registry key to string "0".
The key referred to is OptIn. According to that page, it is located in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\VisualStudio\SQM, although it could also be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VSCommon\14.0\SQM (this was the case in my Windows 10 laptop).
(The Microsoft page also says it should be a string, but in my case it's a DWORD and it works fine.)
Or should I contact the unbox developer and have him add that file to the db?
What's happening is that Tup, a file-based build system, requires that all outputs of a command be specified, but this file is not, and so Tup complains when it detects that it's written to. For Tup, there is no difference between creating and writing to a file — in both cases, it's an ‘output’. Thus, Tup doesn't handle situations in which several commands write to the same file. This often causes problems with caches, which are designed to be written to incrementally. If I recall correctly, Tup has a workaround implemented whereby it ignores output files whose path comprises any component with a leading period. In Linux environments, a directory whose name starts with a leading period is considered ‘hidden’, unlike in Windows, where this feature is implemented with a file-system attribute. This workaround thus generally fails with Windows native tools, which don't rely on such naming convention. A more flexible solution on Tup's side would be a way of telling Tup to ignore certain outputs, either in a system or user basis or from within Tupfiles.
It wouldn't be possible to list this file as an output because it would become an output of all invocations of CL.EXE (and possibly other Visual Studio tools), and this doesn't make sense per Tup's design. There's definitely no intention to make room in it for files which are read from and written to by the same command, since it's impossible to automate such scenario. Even if this file was only written to, I think there are no intentions to support incrementally-written outputs.
Since the project seems to be committed to some platforms and provides build instructions for them, it seems reasonable to point out the issue and the solution to them so they can include it in the instructions.
Related
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
I'm trying to migrate some C programs from Windows Server to Linux. To edit the code, I'm using Eclipse-Indigo. The machine on which I'm working has WinXP on it (not my choice, so no comments please). My eclipse workarea is on a samba shared drive which is in my home directory on the Linux server.
Each C program is in a separate makefile project. I have specified the cygwin gcc compiler/parser in the settings for new CDT Projects and selected all relevant error parsers in the makefile project settings.
There are no syntax errors showing and the errors that are listed seem somewhat bizarre. The first error states:
make: *** No rule to make target `../../../../../fiscus/vo/src/mk/e12_.mk'. Stop.
The make script at the end is wrong. There is a value in the name which comes from an environment variable. The path is correct exactly as shown but the script name has hte variable $(WA_PLATFORM) in it. This is not being resolved although I have specified the value in the build environment variables.
The subsequent errors are even weirder. For each subsequent project I get the message:
Program "make" is not found in PATH
This makes me wonder how the first message was generated. Besides, the path on my winXP environment, which I assume is the relevant one here, does indeed have the directory with the make program in it.
Where have I mucked it up? Any hints?
One last piece of information. When I shut down eclipse I get access violation errors for the following:
<workarea-path>\.metadata\plugins\org.eclipse.debug.ui\launchConfigurationHistory.xml
<workarea-path>\.metadata\plugins\org.eclipse.jdt.core\variablesAndContainers.dat
I find this to be suspicious...
The problem appears to lie in the fact that I was using the samba share as my workarea. Apparently the regular backups made on the server changed something (don't know exactly what, though). The projects were no longer being recognised as makefile projects and certain essential metadata files were not accessible. The permissions certainly were not the problem, since I checked those on the server (everything was set to rwxrwxrwx).
To solve the problem I copied the entire workarea to my local hard drive. I then pointed eclipse at this new workarea. The next step was a bit of a pain, because I had to delete each project (without deleting the source, of course) and then import "Existing code as Makefile Project". This can be done with "File->import..." or with a right-click in the package explorer and select "import...".
The last requirement is to specify the required "include" directories. This can be done with "Project-> Properties-> C/C++ General-> Paths and Symbols". Select the "Includes" tab, choose the language (in this case "GNU C") and add the directories where the headers are defined.
Now it works properly again.
Using a lerping rectangle class in openFrameworks. I then tried to instantiate it as an array, but it crashed with error:
"warning: Could not find object file "/Users/mike/Projects/simbl/build/SIMBL.build/Deployment/SIMBL.build/Objects-normal/i386/SIMBLPlugin.o" - no debug information available for "/Users/mike/Projects/simbl/src/SIMBLPlugin.m".
The release build was slightly more stable than the debug.
When commenting out these two lines (within a function called continuously throughout the array of its class), it runs fine.
pos.x = catchUpSpeed * mouseX + (1-catchUpSpeed) * pos.x;
pos.y = catchUpSpeed * mouseY + (1-catchUpSpeed) * pos.y;
catchUpSpeed is .03f
Any thoughts on the error message? How did this error arise and how can it be avoided? I can't make heads or tails of it. Seems like simple enough math.
Thank you for reading!
You shouldn't see a crash if this happens, or rather, a crash shouldn't be caused by/related to this warning.
There are two ways to build your app with debug information on Mac OS X / iOS: "DWARF" and "DWARF with dSYM". (these are options in your Xcode project Build Settings)
"DWARF" means that the debug information exists in your .o (object) files. It is not copied into the final executable binary for your app. Your app binary has pointers back to the debug information in the object files. This helps to speed up the link & run cycle. But for it to work, your object files need to be located in the same place as when your built your app. Copying your app to another computer would likely break this. Removing your build intermediates would result in the same problem. The "DWARF" debug info scheme is designed for active development on your local desktop where the .o files will remain in place and not be removed while you're debugging your app.
"DWARF with dSYM" means that when your app binary is linked together, another command (dsymutil) is run to create a linked version of all of your debug information -- a .dSYM bundle. This collects all of the debug information from your object files into a single bundle, and it sits next to your binary. If you want to copy your binary to another system to run & debug it, bring the dSYM along and everything will work fine.
I'm not sure how you're using the build system so that this arrangement is failing for you at debug time, but if you're doing something behind the scenes so that your SIMBLPlugin.o object file does not exist wen you're debugging your app, try changing your project to DWARF with dSYM and you should be fine.
If Xcode is crashing, it's unlikely to be related to that warning message from the debugger. But it would be worth filing a bug report if you're seeing this with a current (Xcode 4.6, etc) version of the tools. http://bugreport.apple.com/ - include the crash reporter text from one of the instances and that'll be a place for them to start.
Using Visual Studio 2003 Professional under Windows 7 SP1 (64 bit), compiling from the command line, I get a fatal error C1074: IDB is illegal extension for PDB file. The documentation on this error is sparse to put it lightly. The incredibly odd thing about this is that, utilizing the same build script on the same computer but under a different account does not generate this error.
My first guess was that something in the environment variables is causing this conflict, but doing a diff between them for the two accounts, and modifying PATH and INCLUDE to be the same does not fix the error.
Does anyone have a fix for this error, or any idea what actually triggers it? None of the files are being compiled with a /Z switch of any kind, so as far as I can tell, no PDB files should ever actually be generated (and on a successful build, no IDB OR PDB files are generated that I can see).
I was experiencing the same problem with solutions on Windows 7 x64 and Visual Studio 2005 Pro (SP1).
Symptoms
I am using Visual Assist X (currently build 2007). So in my case all I needed to do was to disable IntelliSense by renaming feacp.dl inside C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcpackages to something else. That fixed the crash at startup (probably unrelated to the issue the OP encountered).
After that the Debug configuration gave me loads of
fatal error C1033: cannot open program database ''
errors, one per file compiled by cl.exe.
With the Release configuration I got
fatal error C1074: 'IDB' is illegal extension for PDB file: <filename>
i.e. the one about which the OP was asking.
Solution
I found the solution more or less by accident elsewhere, reported for VS 2003. In a sense it's the opposite of Luke's answer.
Fatal Error C1074
This error has been reported to occur if the Windows 7 machines have
Windows XP compatibility mode turned on. To resolve the error, turn
off the Windows XP compatibility mode and recompile the solution.
Should you have other issues check the MSDN forums for more help. Its
not the source it sounds more like your settings with VS. I've never
run across this problem before so I'm little help.
That prompted me to check out the settings for devenv.exe (in my case under C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE). It looks like this:
In my case it was set to be compatible with Windows 2003 Server as depicted in the above screenshot. However, the compatibility must be turned off! (checkbox unchecked)
Also make sure to check out and correct the settings for all users by clicking the second highlighted button (UAC prompt will show up if you aren't already running privileged).
This solved the problem for me and I can avoid running VS 2005 Pro elevated all the time.
From information I've gathered on MSDN about issues similar, but not exactly the same:
Since it compiles with no other change than the user account, I believe there's a chance that it could have something to do with the user accounts permissions. Check and see the differences between the users permissions in VS's settings, and in Windows User Settings. The first thing I would try though is to close VS, reopen with Run As Administrator using the account that WON'T compile and see what happens.
In the attempt of sharing the solutions of some of my troubles, and in the hope of sparing them to others, I had the same issue trying to compile a legacy solution in VS2005/SP1 inside a Win8-x64 machine.
No matter what I tried to do, it always stopped there complaining about the illegal IDB extension...
On the other side, the very same solution compiled flawlessly in my previous Win7-x64 box, when run "elevated".
After much struggling I found that I had to use Win8 "Program Compatibility Assistant" (or whatever is named in the english version - my OS is using a different language) and tell it to run VS2005 in a Win7 elevated environment. After that, the obscure "IDB is illegal" error disappeared at once!
Hope this will help someone =)
I have an image processing C program which uses OpenCV library. I was developing this with Visual Studio 2008 until this happened. So I moved the whole project to netbeans(6.9) and MinGW.
I have configured netbeans to use OpenCV libraries as guided in this blog.
But when I run the program it gives this error " The application failed to initialize properly (0xc0150002) "
I don't think this happens when trying to read any image files from the hard disk. It gives the error without even executing 1st line in the main method.
The only change I made to the code is this.
static __inline void release_mem( CvPoint2D64f*, CvPoint2D64f*, static struct feature** );
this gave me error : storage class specified for parameter 'type name'
so I changed the code to (Trial and error rather than any logic)
static __inline void release_mem( CvPoint2D64f*, CvPoint2D64f*, struct feature** );
It is a side-by-side configuration problem. Your program contains a manifest that states what DLL it needs from the SxS cache. And Windows can't find it. Start by looking at the Windows event log, it will tell you what DLL couldn't be found.
This is more typically a VS2008 problem, its DLL version of the CRT libraries are stored in the side-by-side cache. Like msvcrt90.dll. Maybe you didn't quite manage to get the code converted to your new build environment. Which is odd, embedding the manifest is an explicit build step. Do check that you don't have a .manifest file in your build directory.
This hoopla got retired in VS2010 btw. VS2010 Express could be your 3rd attempt.