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.
Related
assembly file is a intermediate product of make process.
I want to edit assembly files, and apply this assembly file(*.s) to the process of make.
Make process is like below.
generate *.ii from the *.cpp files.
generate *.s from the *.ii files.
assemble *.o from the *.s files.
Finally, linker links *.o files to and generate the final binaries.
What I want to do:
Modify the assembly files (*.s files) after step 2.
Then modified assembly files to be reflected in the next step of make.
What I tried:
I copied the modified assembly file to target directory typed make all.
But modified assembly file didn't reflected in the result binary because make process re-generate assembly file inside target directory.
Is there a way to apply user-defined assembly files into the make process?
I would like to edit an existing software to add a new source file (Source.cpp).
But, I can't manage the compilation process (it seems to be automake and it looks very complicated).
The software (iperf 2: https://sourceforge.net/projects/iperf2/files/?source=navbar) is compiled using a classical ./configure make then make install.
If I just add the file to the corresponding source and include directory, I got this error message:
Settings.cpp:(.text+0x969) : undefined reference to ...
It looks like the makefile isn't able to produce the output file associated with my new source file (Source.cpp). So, I probably need to indicate it manually somewhere.
I searched a bit in the project files and it seemed that the file to edit was: "Makefile.am".
I added my source to the variable iperf_SOURCES in that file but it didn't workded.
Could you help me to find the file where I need to indicate my new source file (it seems a pretty standard compilation scheme but I never used automake softwares and this one seems very complicated).
Thank you in advance
This project is built with the autotools, as you already figured out.
The makefiles are built by automake. It takes its input in files that usually have a am file name extension.
The iperf program is built by the makefile generated from src/Makefile.am. This is indicated by:
bin_PROGRAMS = iperf
All (actually this is a simplification, but which holds in this case) source files of a to be built binary are in the corresponding name_SOURCES variable, thus in this case iperf_SOURCES. Just add your source file to the end of that list, like so (keeping their formatting):
iperf_SOURCES = \
Client.cpp \
# lines omitted
tcp_window_size.c \
my_new_file.c
Now, to reflect this change in any future generated src/Makefile you need to run automake. This will modify src/Makefile.in, which is a template that is used by config.sub at the end of configure to generate the actual makefile.
Running automake can happen in various ways:
If you already have makefiles that were generated after an configure these should take care of rebuilding themselves. This seems to fail sometimes though!
You could run automake (in the top level directory) by hand. I've never done this, as there is the better solution to...
Run autoreconf --install (possibly add --force to the arguments) in the top level directory. This will regenerate the entire build system, calling all needed programs such as autoheader, autoconf and of course automake. This is my favorite solution.
The later two options require calling configure again, IMO ideally doing an out of source built:
# in top level dir
mkdir build
cd build
../configure # arguments
make # should now also compile and link your new source file
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
I have a bunch of C++ programs each in its own sub-directory. Each sub-directory has a single C++ program in several files -- a .h and a .cpp file for each class plus a main .cpp program. I want to compile each program placing the executable in the corresponding sub-directory. (I also want to run each program and redirect its output to a file that is placed in the corresponding sub-directory but if I can get the compilation to work, I shouldn't have a problem figuring out this part.)
I'm using the bash shell on a UNIX system (actually the UNIX emulator Cygwin that runs on top of Windows).
I've managed to find on the web, a short scrip for compiling one-file programs in the current directory but that's as far as I've gotten. That script is as follows.
for f in *.cpp;
do g++ -Wall -O2 "$f" -o "{f/.cpp/}";
done;
I would really appreciate it someone could help me out. I need to do this task on average once every two weeks (more like 8 weeks in a row, then not for 8 weeks, etc.)
Unless you're masochistic, use makefiles instead of shell scripts.
Since (apparently) each executable depends on all the .h and .cpp files in the same directory, the makefiles will be easy to write -- each will have something like:
whatever.exe: x.obj y.obj z.obj
g++ -o whatever.exe x.obj y.obj z.obj
You can also add a target in each to run the resulting executable:
run:
whatever.exe
With that you'll use make run to run the executable.
Then you'll (probably) want a makefile in the root directory that recursively makes the target in each subdirectory, then runs each (as described above).
This has a couple of good points -- primarily that it's actually built for this kind of task, so it actually does it well. Another is that it takes note of the timestamps on the files, so it only rebuilds the executables that actually need it (i.e., where at least one of the files that executable depends on has been modified since the executable itself was built).
Assuming you have a directory all of whose immediate subdirectories are all c++ programs, then use some variation on this...
for D in */; do cd "$D";
# then either call make or call your g++
# with whatever arguments in here
# or nest that script you found online if it seems to
# be doing the trick for you.
cd ../;
done;
That will move in to each directory, do its thing (whatever you want that to be) and then move back out.
I have several hundred files in a non-flat directory structure. My Makefile lists each sourcefile, which, given the size of the project and the fact that there are multiple developers on the project, can create annoyances when we forget to put a new one in or take out the old ones. I'd like to generalize my Makefile so that make can simply build all .cpp and .h files without me having to specify all the filenames, given some generic rules for different types of files.
My question: given a large number of files in a directory with lots of subfolders, how do I tell make to build them all without having to specify each and every subfolder as part of the path? And how do I make it so that I can do this with only one Makefile in the root directory?
EDIT: this almost answers my question, but it requires that you specify all filenames :\
I'm sure a pure-gmake solution is possible, but using an external command to modify the makefile, or generate an external one (which you include in your makefile) is probably much simpler.
Something along the lines of:
all: myprog
find_sources:
zsh -c 'for x in **/*.cpp; echo "myprog: ${x/.cpp/.o}" >> deps.mk'
include deps.mk
and run
make find_sources && make
note: the exact zsh line probably needs some escaping to work in a make file, e.g. $$ instead of $. It can also be replaced with bash + find.
One way that would be platform independent (I mean independent from shell being in Windows or Linux) is this:
DIRS = relative/path1\
relative/path2
dd = absolute/path/to/subdirectories
all:
#$(foreach dir, $(DIRS), $(MAKE) -C $(dd)$(dir) build -f ../../Makefile ;)
build:
... build here
note that spaces and also the semicolon are important here, also it is important to specify the absolute paths, and also specify the path to the appropriate Makefile at the end (in this case I am using only one Makefile on grandparent folder)
But there is a better approach too which involves PHONY targets, it better shows the progress and errors and stops the build if one folder has problem instead of proceeding to other targets:
.PHONY: subdirs $(DIRS)
subdirs: $(DIRS)
$(DIRS):
$(MAKE) -C $# build -f ../../Makefile
all : prepare subdirs
...
build :
... build here
Again I am using only one Makefile here that is supposed to be applicable to all sub-projects. For each sub-project in the grandchild folder the target "build" is created usinf one Makefile in the root.
I would start by using a combination of the wildcard function:
http://www.gnu.org/software/make/manual/make.html#Wildcard-Function
VPATH/vpath
http://www.gnu.org/software/make/manual/make.html#Selective-Search
and the file functions
http://www.gnu.org/software/make/manual/make.html#File-Name-Functions
For exclusion (ie: backups, as Jonathan Leffler mentioned), use a seperate folder not in the vpath for backups, and use good implicit rules.
You will still need to define which folders to do to, but not each file in them.
I'm of two minds on this one. On one hand, if your Make system compiles and links everything it finds, you'll find out in a hurry if someone has left conflicting junk in the source directories. On the other hand, non-conflicting junk will proliferate and you'll have no easy way of distinguishing it from the live code...
I think it depends on a lot of things specific to your shop, such as source source control system and whether you plan to ever have another project with an overlapping code base. That said, if you really want to compile every source file below a given directory and then link them all, I'd suggest simple recursion: to make objects, compile all source files here, add the resultant objects (with full paths) to a list in the top source directory, recurse into all directories here. To link, use the list.