Failing to use PGO with error LNK1270 - c++

I'm trying to use Profile Guided Optimization (PGO) with VS8. After instrumenting the DLL in question I copy it over to a machine that has our application installed and run the training scenario. I then copy the pgc training files back to my dev box and get the following error:
1>StdAfx.obj : fatal error LNK1270: invalid file; timestamp does not match file linked with /LTCG:PGINSTRUMENT
The MSDN entry for this error says:
invalid file; timestamp does not match file linked with /LTCG:PGINSTRUMENT
The same files passed to the linker when specifying /LTCG:PGINSTRUMENT must also be passed when specifying /LTCG:PGOPTIMIZE.
/LTCG:PGOPTIMIZE requires that the inputs be identical to the /LTCG:PGINSTRUMENT phase.
To resolve this warning, run /LTCG:PGINSTRUMENT, redo all test runs, and run /LTCG:PGOPTIMIZE, or, create the optimized image with /LTCG:PGUPDATE instead of /LTCG:PGOPTIMIZE.
Rerunning the tests doesn't solve the problem (although it sometimes appears for other files, not stdafx.obj).
Using /LTCG:PGUPDATE does work however I would like to understand what is causing the error, or failing that are there any drawbacks to using PGUPDATE rather than PGOPTIMIZE (I can't find anything relevant in the MSDN PGO page).

Related

How can I solve this error in OMNest 5.5.1?

I get the following error:
Exception occurred executing command line.
Cannot run program "C:/OMNEST-5.5.1/samples/enera/lteAdvanced/enera.exe" (in directory "C:\OMNEST-5.5.1\samples\enera\lte"): CreateProcess error=2, The System cannot find the file.
I already built the project many times. I have tried to make a simplier already given example from omnet just to check if this is working. It is working. But if I copy this example in my Project it also doesn't work, so there is sth wrong with my Project file. But it seems to be correct. I just have one Connection and kept it really really simple. But it doesn't work. I have installed Omnest and inet correctly.
The most likely cause is that the EXE file cannot find the omnet++ dynamic libraries it tries the load. And the most likely reason is that you are trying to execute the executable from a CMD prompt instead of from the shell provided by the mingwenv.cmd script.
Everything you do in OMNeT++ (including starting the simulations) must be run from the mingwenv shell.

Netbeans IDE 8.0.2 C++ Input/Output Error

I installed netbeans C++ on windows 7 and used Cywgin4 as the compiler. When I run any program even a simple Hello world it does compile and run however I also get the error below. I can't seem to find any reference to it online. Can anyone point me in the right direction for a solution? Thanks!
read from master failed
: Input/output error
RUN FAILED (exit value 1, total time: 47ms)
I do not understand all the surrounding details of this problem as I am new to C/C++. However, if you:
Open up NetBeans
Right click on your C++ project file
Select "Properties"
There should be a category called "Run".
Under this category, find the option called Console Type and make sure that Standard Output is selected as shown in the screenshot below:
I was having the same problems when the console type was selected as Internal Terminal.
For my setup, changing this option to Standard Output got rid of this error. However, I do not fully understand how this change affects the overall properties of my project. Wish you good luck.

Compiling code too quickly gives errors

I have recently started coding with C++ and I have come across a little source of error which I think requires knowledge about computers that I don't have.
When I write a simple code (in Visual Studio Express 2013), let's say a "Hello World!" example, I Build and Start Without Debugging successfuly.
Then, when I edit my code to print the sum of two numbers for example, I get an error when I try to Build. I get this error:
Error 1 error LNK1168: cannot open c:\users\name\documents\visual
studio 2013\Projects\ConsoleApplication4\Debug\ConsoleApplication4.exe
for writing
But if I wait for a bit and then re-attempt to Build, everything is fine.
I have also noticed this when I use g++ in the standard cmd module; if I try to complile a code under the same name (for the .exe file) I get an Access Denied error, but if I wait a bit I am allowed to do it.
My instincts tell me that the computer still has the .exe file running for a bit after I execute it, and it is not allowing me to overwrite it.
It's because the process is still running and therefore the file is in use and write-locked. It takes Windows a few tempo beats to clean everything up after you've terminated.

Exe built using pyinstaller on a Django with pylucene app giving JVM error

I am getting an error:
"Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries"
The error arises when I try to execute my exe file.
I have created exe file through pyinstaller on a django application. Application uses pylucine library. I think it may be the issue of error.
How to fix the error?
Since I can't be certain given you've provided very few details here is a shot in the dark to help solve your problem:
First, try removing the jvm.dll file that gets packaged with the pyinstaller -D youmodule.py command (for now work with the directory command rather than -F option). The reason why is here.
With that jvm.dll file gone, you should start seeing the actual error code - and with that the java class or dependency that isn't being loaded.
If it's a java class that isn't being properly loaded then you know instantly it must not be correcly represented in the classpath environment variable and you should do everything in your power to make sure it is:
e.g.: os.environ['CLASSPATH'] += 'the/path/to/the/jar'
Otherwise, consider bulking up your question with more details, especially if you can get a more meaningful error output.
I had the same error trying to run a .exe built with PyInstaller through wine.
My problem went away by adding C:\Program Files\Java\ [your jdk version here] \jre\bin\server to the PATH environment variable in wine - I suppose it might be the same in Windows.
It also reappeared if I tried to build with C:\Program Files\Java\ [your jdk version here] \jre\bin\server in my PATH, so I had to build without it and then append it before running it (I have no explanation as to why this happens).

Strange "No such file or directory" error in cuda-gdb

I already asked this question in the nvidia forum but never got an answer link.
Every time I try to step into a kernel I get a similar error message to this:
__device_stub__Z10bitreversePj (__par0=0x110000) at
/tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c:10
10 /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c
I tried to follow the instructions of the cuda-gdb walkthrough by the error stays.
Has somebody a tip what could cause this behaviour?
The "device stub" for bitreverse(unsigned int*) (whatever that is) was compiled with debug info, and it was located in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c (which was likely machine-generated).
The "No such file" error is telling you that that file is not (or no longer) present on your system, but this is not an error; GDB just can't show you the source.
This should not prevent you from stepping further, or from setting breakpoints in other functions and continuing.
I was able to solve this problem by using -keep flag on the nvcc compiler. This specifies that the compiler should keep all intermediate files created during the compilation, including the stub.c files created by cudafe that are needed for the debugger to step through kernel functions. Otherwise the intermediate files seem to get deleted by default at the end of the compilation and the debugger will not be able to find them. You can specify a directory for the intermediate files as well, and will need to point your debugger (cuda-gdb, nsight, etc) to this location.
I think I had such problem once, but can't really remember what was it caused with. Do you use textures in your kernel? In that case you couldn't debug it.