I have been trying to run a c++ program from https://github.com/rinon/Simple-Homomorphic-Encryption
As specified in the README I have run the following commands,
make
make test
make demo
Now, I have the following files in my directory,
zakirhussain#zakirhussain-K52F:~/Simple-Homomorphic-Encryption$ ls
circuit.cpp demo_vote_counter.cpp fully_homomorphic.cpp main.o security_settings.h test_suite.o utilities.o
circuit.h demo_vote_counter.h fully_homomorphic.h makefile security_settings.o type_defs.h
circuit.o demo_vote_counter.o fully_homomorphic.o README test_fully_homomorphic utilities.c
demo_fully_homomorphic fully_homomorphic main.cpp security_settings.cpp test_suite.cpp utilities.h
Could someone help me with running demo_vote_counter.o file?
An object file (.o) is not executable. You want to be running ./demo_fully_homomorphic (e.g. the file without extension). Make sure you have execute permissions (chmod a+x demo_fully_homomorphic).
You can not run a .o file. This is an object file and has to be linked into the final executable. A .o file is usually lacking additional libraries, which are added at the linking stage.
Looking at your outoput I would assume that one of demo_fully_homomorphic, test_fully_homomorphic or fully_homomorphic are the executables that you can run.
I think I am late, but the code below maybe helpful for someone, I guess.
Using cd into your folder contains the c/c++ file, then compile it.
gcc my_test.c -o my_test
Complied file will be generated. Then still in same folder. Run the command.
./my_test
As already mentioned in several other answers, you can execute a binary file and not the object file. However, Just in case, if what you want is to display the contents of object file in readable format?
$>objdump -d object_filename.o
You can't run the object file. It has to be linked first to make an executable.
As I see there is a "demo_fully_homomorphic" "fully_homomorphic" and a "test_fully_homomorphic" in your directory. Those are your linked executables, you may execute them with ./[executable_name]
In this case the executable is called demo_fully_homomorphic, try
./demo_fully_homomorphic
Related
Suppose I get myProgam executable file on Mac as a result of compiling my code like this:
gcc -o myProgram myProgram.c
How can induce my .gitignore file to actually ignore the myProgram file? I'm not looking for the solution where I make a separate folder for my executable files.
My question might seem obvious to many but I cannot actually find any solution online although I've searched a few pages and tutorials already as well as the StackOverflow resources.
I'll be grateful for any hints.
Add
myProgram
on a separate line in your .gitignore file
I have taken my first two courses in java and now have to take Data Structures in C++. I'm trying to open up the different files I've compiled.
They're just two "Hello, world!" programs with slightly different text.
When I type:
g++ HelloWorld.cpp
The file "a.out" is created which I run by typing ./a.out into the command prompt.
Now that I compiled a second executable program, HelloWorldII.cpp, the a.out file only runs that program.
When I try to run ./HelloWorld.cpp I got permission denied, so I typed in:
sudo chmod 744 /Users/username/HelloWorld
to make me the owner of the folder which didn't work so I typed in:
sudo chown -R "$garyjones:" users/username/HelloWorld
to give the owner(me) permission to edit/open, after which when I attempted to run ./HelloWorld.cpp, terminal began to attempt executing it but instead showed me syntax error even though compiling them with g++ HelloWorld.cpp and running them with their a.out files worked fine.
If I have multiple executable files in a folder, how can I open the one I want?
When you compile and link code, the executable is by default named a.out - you are supposed to add a parameter to the linking to name it.
If you don’t do it, they are all going to be named a.out, and of course overwrite each other - there can be only one file with that name.
It is strange for you attempting to execute a pure ascii text file. You don't understand the execution mode's meaning. You are not familiar with g++. It seems like you don't know the process of how an executable file generated by compiler from source file.
And here is my advice.
Google the basic usage of g++ or some other compilers. Choose your favourite.
Here is the temporary solution.
g++ <source file> -o <executable filename>
Example:
## if you don't specific a name for the binary file,
## it will generate a.out and delete the exiting a.out firstly
g++ HelloWorld.cpp -o HelloWorld
## and then you can execute it
./HelloWorld
Figure out what the exact meaning of file permission.
The a.out filename has traditional reason and I recommend you to explore it. It's funny.
I am using gcov as my code coverage tool for my c++ project with gcc (currently 4.6.3 but soon to be 4.8) on Ubuntu 12.04 and am getting the error cannot open graph file. What does this error mean? And how do I get rid of it so that I can see my code coverage?
I've seen other solutions to this problem the most popular being to use clang (gcov: cannot open graph file) instead of gcc but I can't switch compilers, I have to use gcc so that is not a workable solution for me. Plus, the documentation on gcov says that it should work with gcc.
Another solution was to fix a configuration file (http://ubuntuforums.org/showthread.php?t=1547252) but I'm not sure what configuration file this user is speaking of so if that is my problem as well I don't know how to fix it
my .gcda and .gcno files are correctly being generated in my obj directory
beyond going into my top directory where I compile my code and doing gcov *.c I'v also tried
gcov -o directory/to/obj *.c
and
gcov -o directory/to/obj *.gcda
and
gcov -o directory/to/obj *.gcno
but none of these solutions work; i still get the cannot open graph file error.
Any help or advice would be appreciated!
The above problem is due to absence of .gcda and .gcno file in the directory where your source code present .
So my suggestion is 1st copy one .gcda and .gcno file of particular .c file in your source code where your .c resides then execute gcov filename.c.
If you get coverage ,then try to soft link all your .gcda and .gcno to source code if dont want to copy from obj directory then as u stated problem ll be solved
Let me clarify few of the things that you were doing wrong.
First: you always tried to specify *.gcda, *.gcno, *.c etc after obj directory path, which is totally wrong.
What you need to do is to specify it as "-o path/to/obj/ " (path to directory)
You can even specify path to gcda file of that particular c/c++ source file and specify path to obj directory in "-o" flag to get the report for that file.
And if you use gcovr instead of gcov for your reports then you can get all the kind of reports by specifying only the root directory (directory above src & obj) with "-r -root=ROOT" flag.
Refer to this user guide for details on gcovr.
I'm quite confused about this weird behaviour of my .cpp project. I've got the following folder structure:
include/mylib.h
myproject/src/eval.cpp
myproject/data/file.csv
myproject/Makefile
In eval.cpp I include mylib.h as follows:
#include "../../include/mylib.h"
and compile it through Makefile:
all:
g++ -I include ../include/mylib.h src/eval.cpp -o eval.out
Now in my eval.cpp I'm reading the file.csv from data directory and if I refer to it like this
../data/file.csv
it doesn't find it (gets empty lines all the time), but this
data/file.csv
works fine.
So, to include mylib.h it goes two directories up (from src folder) which seems right. But it doesn't make sense to me that to refer to another file from the same piece of code it assumes we are in project directory. I suppose it is connected with Makefile somehow, but I'm not sure.
Why is it so?
EDIT: After a few thing I tried it seems that the path which is used is not the path from binary location to the data location, but depends on where from I run the binary as well. I.e., if I have binary in bin directory and run it like:
./bin/eval.out
It works with data/file.csv.
This:
cd bin
./eval.out
works with ../data/file.csv.
Now it seems very confusing to me as depending on where I run the program from it will give different output. Can anyone please elaborate on the reasons for this behaviour and if it is normal or I'm making some mistake?
It is so because (as explained here ) the compiler will search for #included files with quotes (not with brackets) with the current working directory being the location of the source file.
Then, when you try to open your .csv file, it's now your program that looks for a file. But your program runs with the current working directory being myproject/ which explains why you must specify data/file.csv as your file path, and not ../data/file.csv. Your program does not run in your src folder, it will run in the directory the binary ends up being invoked from.
You could have noticed that in your Makefile, your -I options specify a different path for your header file than your .cpp file.
EDIT Answer: It's quite simple actually and completely normal. When you invoke your binary, the directory which you're in is the current working directory. That is, if you run it with the command ./myproject/bin/eval.out, the current working directory is . (e.g. /home/the_user/cpp_projects). My post was a bit misleading about that, I corrected it.
Note: You can use the command pwd in a command prompt to know which is the current working directory of this prompt (pwd stands for "print working directory").
I ma trying to run examples using a library. In the documentation to the library it is written that I need to copy all the files into my directory and than type make. After that I need to go to the "Debug" folder and type ./lib_examples to run the examples.
I performed this sequence. As a result I have a lot of *.o and *.d files in the "Debug" subdirectory. Among them there is lib_examples.o and lib_examples.h files. But there is no lib_example file that I am supposed to execute.
Does anybody know what was supposed to happen and where it went wrong. Should I do one more step to be able to use *.o and *.d files?
The ".o" files are likely intermediate files from which the actual executable program should have been created.
The ".d" files are likely internal state used by the makefile, only important if you are making changes to the source code and then rebuilding "incrementally".
If, after running make, you have only these files but not the executable file, then the most likely explanation is that make encountered an error in creating the executable. If that's the case, then the last few lines of output generated by make should tell you more.