I've compiled and linked my application with -pg, and when running the application I get the correct gmon.out file and can analysis it with gprof. I am running a number of scripts under different situations to discover a speed issue between two versions of our software.
When I run the application I do produce the gmon.out output.
Since I have to do this for a number of different scripts, I piled them into a scrip to run so I can take a nap. It's not complicated. I'm also running this script at the same time in another directory with the other version of the application.
./test test1.script
gprof test > test1.ver1.stats
rm -f gmon.out
./test test2.script
gprof test > test2.ver1.stats
rm -f gmon.out
These do not produce the gmon.out file. Is there any explanation to this behavior? Also, running the script without the analysis of the other version running (eg, concatenate the scripts instead of running them in parallel), also produces the same behavior.
The scripts I am using to test the application change directories to get a large data-set. This affected the gmon.out location so when the application exited it was written to that far off directory. As the GNU GProf manual says,
The gmon.out file is written in the program's current working
directory at the time it exits. This means that if your program calls
chdir, the gmon.out file will be left in the last directory your
program chdir'd to. If you don't have permission to write in this
directory, the file is not written, and you will get an error message.
Last night I had the scripts running like,
GMON_OUT_PREFIX=test1.ver1.out ./test test1.script
GMON_OUT_PREFIX=test2.ver1.out ./test test2.script
GMON_OUT_PREFIX=test3.ver1.out ./test test3.script
And although, I couldn't find the files in my working directory, I did eventually find the files in the data folder. In the above, it is not important to specify different names for the output since they are proceeded by their process id (like, GMON_OUT_PREFIX.PID), but was necessary in my case to distinguish the tests.
Related
I'm working with Windows.
I have a program in a fortran 90 file ..\my_folder\my_file.f90 that yields an output file ..\my_folder\output.dat.
I'd like to run this file many times simultaneously (to get statistics from multiple stochastic simulations). But this cannot be done in one folder. I get the error message : cannot open output file a.exe: Permission denied collect2.exe: error: ld returned 1 exit status.
And I don't want to copy-past it to different folders ..\my_folder\new_folder0\my_file.f90,..\my_folder\new_folder1\my_file.f90... since this is not convenient if I want to modify a line inside the fortran file.
I would like to know what tool I can use to make one fortran file run from different folders ?
And how is it possible to make it run but with different parameters please, so that in each folder the fortran file is run with different parameters ?
From the error message it seems also that if there was different .exe files and not only a.exe it would be ok. Is there a way that each time I compile the fortran file it would give a different .exe program to run ?
I have a program that exists in the /usr/local/flower directory - flower.rb. It requires loading libraries that also exist in the same directory. I've included this flower directory in my OS environment's path. And my choice of OS is Ubuntu.
When I execute flower.rb from any other directory other than /usr/local/flower, I get error messages indicating the program can't load the libraries that also exist in the /usr/local/flower directory b/c they are being loaded as ./[library] from source code.
I realize I could change the Ruby program to hard code the /usr/local/flower/[libraries], but I'm curious if there's a way to execute this program from my home directory, e.g. /home/seattle, w/o doing this.
Also, when the program executes, it creates output via the -o switch.
My solution was to create a bash script that changed to the /usr/local/flower directory, executed the program, and then return to the PWD directory from where the flower.rb program was called. The problem is the -o switch. If I do a -o [file] the [file] gets written to the /usr/local/flower directory as opposed to where I am when the flower.rb program is run.
What is a good solution for this problem?
It's not quite clear from your question, but it appears that you are using require wrongly. require is for loading scripts from the $LOAD_PATH. If you want to load a script relative to the directory of the current script, use require_relative.
You should never load scripts relative to the current working directory. The current working directory is under the control of the user, not your script. You have no idea what it is gonna be. There is a reason why the current working directory was removed from the $LOAD_PATH in 2008: because it's broken.
I'm trying to generate a c++ project using cmake on Windows 7. Before it actually makes the project though it looks cmake does a quick test of your toolchain (I'm using MinGW) and that's where my problem. Cmake triggers a make build which ultimately fails with the response "The system cannot find the path specified."
I ran the particular makefile that was failing in dry run mode (-n) and manually executed all the commands:
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
echo Building C object CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj
C:\PROGRA~2\CODEBL~1\MinGW\bin\gcc.exe -o CMakeFiles\cmTryCompileExec306416588.dir\testCCompiler.c.obj -c C:\SFML\CMakeFiles\ CMakeTmp\testCCompiler.c
echo Linking C executable cmTryCompileExec306416588.exe
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\cmTryCompileExec306416588.dir\link.txt --verbose=1
And they all executed without error leaving me with a functional .exe file as expected. However when run through make I return the error:
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
The system cannot find the path specified.
mingw32-make.exe: *** [CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj] Error 1
I then experimented with replacing all of the commands with something simple like "dir" and noticed that when run through make is returned "The system cannort find the path specified" again before printing out the dir information and exiting with an error.
My next step, and about as far as I've gotten, is to run make with the -d flag; the interesting bit being:
Creating temporary batch file C:\Users\CJ\AppData\Local\Temp\make8664-1.bat
Batch file contents:
#echo off
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
CreateProcess(C:\Users\CJ\AppData\Local\Temp\make8664 1.bat,C:\Users\CJ\AppData\Local\Temp\make8664-1.bat,...)
Putting child 00490378 (CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj) PID 4730176 on the chain.
Live child 00490378 (CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj) PID 4730176
Main thread handle = 00000074
The system cannot find the path specified.
Reaping losing child 00490378 PID 4730176
Cleaning up temp batch file C:\Users\CJ\AppData\Local\Temp\make8664-1.bat
mingw32-make.exe: *** [CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj] Error 1
I don't really know too much about the inner workings of make but from what I can tell from this output it looks like it has something to do with the temporary batch file that make is making. I looked at this stackoverflow post What causes GNU Make to shell out and it looks like what triggers a temporary file to be made is pretty vague. I was able to find a command that executed without the creation of a temporary batch file ("ls" from the windows Git bin) and sure enough it executed via make without returning the "The system cannot find the path specified" response like the "dir" command did ("dir" caused make to generate that temp file).
I feel like I've kind of hit a wall with my debugging abilities and am turning to you guys to see if you can offer any advice. Does it seem like I'm making the right assumptions? Do you have any insights into what may be manifesting the problem?
It looks like I was able to figure out the problem on my own so sorry for bothering with the post. It turns out that the problem wasn't with Make but instead with cmd itself (which would explain the error whenever make tried to run a batch file). It looks like somehow (possibly through some kind of malware that snuck onto my system or maybe some kind of misguided windows update) the Command Processor's registry key was set to something like "C:\Users\CJ\AppData\Roaming\Microsoft\Windows\IEUpdate\RMActivate_ssp.exe" which I recall specifically wiping from my computer not too long ago, hence the "The system cannot find the path specified." message whenever a cmd process was spawned by make (I guess I just totally missed it when I opened up the root cmd process). In any case, this was a simple fix following the instructions at https://superuser.com/questions/727316/error-in-command-line-the-system-cannot-find-the-path-specified, after which I was able to run the make, and subsequently cmake, build without any problems.
The keys in question are
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun and/or HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
Also this error can occur if you picked MSYS toolset in Cmake, but running it under a normal shell. In this case make tries to compile something like /c/source/build/stuff.cpp and normal Windows ABI rejects this path.
A great diagnostic method for this issue is --debug-trycompile flag for Cmake. If something has gone bad, you can re-run the failed command manually or peek into generated files to find the cause.
I've always mentally regarded the current directory as something for users, not scripts, since it is dependent on the user's location and can be different each time the script is executed.
So when I came across the Java jar utility's -C option I was a little puzzled.
For those who don't know the -C option is used before specifying a file/folder to include in a jar. Since the path to the file/folder is replicated in the jar, the -C option changes directories before including the file:
in other words:
jar -C flower lily.class
will make a jar containing the lily.class file, whereas:
jar flower/lily.class
will make a flower folder in the jar which contains lily.class
For a jar-ing script I'm making I want to use Bourne wild-cards folder/* but that would make using -C impossible since it only applies to the next immediate argument.
So the only way to use wild-cards is run from the current directory; but I still feel uneasy towards changing and using the current directory in a script.
Is there any downside to using the current directory in scripts? Is it frowned upon for some reason perhaps?
I don't think there's anything inherently wrong with changing the current directory from a shell script. Certainly it won't cause anything bad to happen, if taken by itself.
In fact, I have a standard script that I use for starting up a Java-based server, and the very first line is:
cd `dirname $0`
This ensures that the rest of the commands in the script are executed in the directory that contains the script file itself (useful when a single machine is hosting multiple server instances), regardless of where the shell script was actually invoked from. Without changing the current directory in the script, it would only work correctly if the user remember to manually cd into the corresponding directory before running the script.
In this case, performing the cd operation from within the script removes a manual step from the server startup/shutdown process, and makes things slightly less error-prone as a result.
So as with most things, there are legitimate uses for this sort of thing. And I'm sure there are also some questionable ones, as well. It really depends upon what's most appropriate for your specific use-case. Which is something I can't really comment on...I always just let maven build my JAR's for me.
I was wondering what else is actually needed in order to run lcov in windows command line? Every time when I run perl lcov, I always get a reminder or errors similar to the following:
geninfo: ERROR: need tool gcov!
I looked into my bin directory, and couldn't find a gcov.exe.
I normally do perl genhtml filename to get a html test coverage report of my javascript. I was trying to see if I can do perl lcov as I might want to combine several lcov files into one (and get the total test coverage).
Thanks.
It sure does look like you need gcov, doesn't it!
(For cygwin, it looks to be part of the gcc4-core package.)