I tried to download cygwin to run my makefile but I get the following error:
> make
FIND: formato del parametro non corretto
FIND: formato del parametro non corretto
g++ -o esempio
g++.exe: fatal error: no input files
compilation terminated.
makefile:12: recipe for target 'esempio' failed
make: *** [esempio] Error 1
This is my basic makefile:
PHONY: all clean
CPPSOURCES += $(shell find . -name '*.cpp')
clean:
rm esempio
all: esempio
#true
esempio: $(CPPSOURCES)
g++ $(CPPSOURCES) -o esempio
what can I do to fix it?
Two things look unusual to me. First is this:
CPPSOURCES += $(shell find . -name '*.cpp')
You usually use wildcard instead of find. I would change it to the following:
CPPSOURCES = $(sort $(wildcard *.cpp))
CPPOBJECTS = $(CPPSOURCES:.cpp=.o)
Second, for your esempio recipe, use CPPOBJECTS instead of CPPSOURCES:
esempio: $(CPPOBJECTS)
$(CXX) $(CXXFLAGS) $(CPPOBJECTS) -o esempio
The use of true in one recipe also looks kind of odd (but it appears to work). You could change it to the following and move it to the top of the file so it is the default recipe:
.PHONY: all
all esempio: $(CPPOBJECTS)
$(CXX) $(CXXFLAGS) $(CPPOBJECTS) -o esempio
Here is an example of a makefile that uses a lot of GNU extra features.
You have the dos command directory ahead of the cygwin bin directory in the PATH.
This is my cygwin path:
$ echo $PATH
$HOME/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Go/bin:/bin
The only windows directory is the golang bin directory. Use cygpath the find the cygwin equivalent directory name.
The simplest way to do this is to remove all windows directories and only add back the few you need. To do this, modify your user environment variables to add CYGWIN_NOWINPATH=1. In your .bashrc you can add back the cygwin equivalent for only those windows directories that you find you really need.
Related
I have the following sub-section of makefile that's used to generate the .d files
-include $(wildcard $(patsubst %,$(OBJ_PATH)/%.d,$(basename $(SRCS))))
%.o: %.cpp
#$(CC) -I$(INCLUDE_PATH) $(CFLAGS) $< -MM -MT $(#:.d=.o) > $(OBJ_PATH)/$(notdir $*.d)
${CC} -I$(INCLUDE_PATH) $(CFLAGS) -c $< -o $(OBJ_PATH)/$(notdir $#)
Sometimes when I build the project, I get the following error /bin/sh: /path/to/my/build/dir/file.d: File exists, although .d files does not exist.
Then I keep getting this error, the only way to get rid of it is to remove the whole enclosing directory and use git restore and the system will build successfully.
System info:
git version 2.27.0
GNU Make 4.2.1
Red Hat Enterprise Linux 8.5 (Ootpa)
Free inodes: 426798634
You should remove the # from your line that creates the .d file, so you can see what the command line actually is. It's always a bad idea to add # before your makefile is working 100% correctly. Then you could cut and paste a full failure example into your question, including the command that generated the error message.
Your build lines are not right. During the compilation, you need to use $# not $(OBJ_PATH)/$(notdir $#). It's always wrong to build a file that is not exactly $#.
During the creation of the dependency file $(#:.d=.o) is useless because $# is already set to xxx.o so changing the .d suffix to .o doesn't do anything. You should just use -MT $# here.
You can replace $(OBJ_PATH)/$(notdir $*.d) with the simpler %*.d.
This error is being shown by the shell and there's really no way we can understand what the problem is with the info given. Why would the shell give a "File exists" error when you use ">" to overwrite it?
I have a suspicion that it's not actually this command that is generating that error.
I am wondering why gcc/g++ doesn't have an option to place the generated object files into a specified directory.
For example:
mkdir builddir
mkdir builddir/objdir
cd srcdir
gcc -c file1.c file2.c file3.c **--outdir=**../builddir/objdir
I know that it's possible to achive this with separate -o options given to the compiler, e.g.:
gcc -c file1.c -o ../builddir/objdir/file1.o
gcc -c file2.c -o ../builddir/objdir/file2.o
gcc -c file3.c -o ../builddir/objdir/file3.o
... and I know that I can write Makefiles via VPATH and vpath directives to simplify this.
But that's a lot of work in a complex build environment.
I could also use
gcc -c file1.c file2.c file3.c
But when I use this approach my srcdir is full of .o garbage afterwards.
So I think that an option with the semantics of --outdir would be very useful.
What is your opinion?
EDIT: our Makefiles are written in such a way that .o files actually placed into builddir/obj. But I am simply wondering if there might be a better approach.
EDIT: There are several approaches which place the burden to achieve the desired behavior to the build system (aka Make, CMake etc.). But I consider them all as being workarounds for a weakness of gcc (and other compilers too).
This is the chopped down makefile for one of my projects, which compiles the sources in 'src' and places the .o files in the directory "obj". The key bit is the the use of the patsubst() function - see the GNU make manual (which is actually a pretty good read) for details:
OUT = lib/alib.a
CC = g++
ODIR = obj
SDIR = src
INC = -Iinc
_OBJS = a_chsrc.o a_csv.o a_enc.o a_env.o a_except.o \
a_date.o a_range.o a_opsys.o
OBJS = $(patsubst %,$(ODIR)/%,$(_OBJS))
$(ODIR)/%.o: $(SDIR)/%.cpp
$(CC) -c $(INC) -o $# $< $(CFLAGS)
$(OUT): $(OBJS)
ar rvs $(OUT) $^
.PHONY: clean
clean:
rm -f $(ODIR)/*.o $(OUT)
How about changing to the directory and running the compile from there:
cd builddir/objdir
gcc ../../srcdir/file1.c ../../srcdir/file2.c ../../srcdir/file3.c
That's it. gcc will interpret includes of the form #include "path/to/header.h" as starting in the directory the file exists so you don't need to modify anything.
A trivial but effective workaround is to add the following right after the gcc call in your Makefile:
mv *.o ../builddir/objdir
or even a soft-clean (possibly recursive) after the compilation is done, like
rm -f *.o
or
find . -name \*.o -exec rm {} \;
You can use a simple wrapper around gcc that will generate the necessary -o options and call gcc:
$ ./gcc-wrap -c file1.c file2.c file3.c --outdir=obj
gcc -o obj/file1.o -c file1.c
gcc -o obj/file2.o -c file2.c
gcc -o obj/file3.o -c file3.c
Here is such a gcc_wrap script in its simplest form:
#!/usr/bin/perl -w
use File::Spec;
use File::Basename;
use Getopt::Long;
Getopt::Long::Configure(pass_through);
my $GCC = "gcc";
my $outdir = ".";
GetOptions("outdir=s" => \$outdir)
or die("Options error");
my #c_files;
while(-f $ARGV[-1]){
push #c_files, pop #ARGV;
}
die("No input files") if(scalar #c_files == 0);
foreach my $c_file (reverse #c_files){
my($filename, $c_path, $suffix) = fileparse($c_file, ".c");
my $o_file = File::Spec->catfile($outdir, "$filename.o");
my $cmd = "$GCC -o $o_file #ARGV $c_file";
print STDERR "$cmd\n";
system($cmd) == 0 or die("Could not execute $cmd: $!");
}
Of course, the standard way is to solve the problem with Makefiles, or simpler, with CMake or bakefile, but you specifically asked for a solution that adds the functionality to gcc, and I think the only way is to write such a wrapper. Of course, you could also patch the gcc sources to include the new option, but that might be hard.
I believe you got the concept backwards...?!
The idea behind Makefiles is that they only process the files that have been updated since the last build, to cut down on (re-)compilation times. If you bunch multiple files together in one compiler run, you basically defeat that purpose.
Your example:
gcc -c file1.c file2.c file3.c **--outdir=**../builddir/objdir
You didn't give the 'make' rule that goes with this command line; but if any of the three files has been updated, you have to run this line, and recompile all three files, which might not be necessary at all. It also keeps 'make' from spawning a seperate compilation process for each source file, as it would do for seperate compilation (when using the '-j' option, as I would strongly suggest).
I wrote a Makefile tutorial elsewhere, which goes into some extra detail (such as auto-detecting your source files instead of having them hard-coded in the Makefile, auto-determining include dependencies, and inline testing).
All you would have to do to get your seperate object directory would be to add the appropriate directory information to the OBJFILES := line and the %.o: %.c Makefile rule from that tutorial. Neil Butterworth's answer has a nice example of how to add the directory information.
(If you want to use DEPFILES or TESTFILES as described in the tutorial, you'd have to adapt the DEPFILES := and TSTFILES := lines plus the %.t: %.c Makefile pdclib.a
rule, too.)
Meanwhile I found a "half-way" solution by using the -combine option.
Example:
mkdir builddir
mkdir builddir/objdir
cd srcdir
gcc -combine -c file1.c file2.c file3.c -o ../builddir/objdir/all-in-one.o
this "combines" all source files into one single object file.
However, this is still "half-way" because it needs to recompile everything when only one source file changes.
I think that telling pass gcc doesn't have an separate option to say where to put object file, since it already has it. It's "-c" - it says in what directory to put object.
Having additional flag for directory only must change meening of "-c".
For example:
gcc -c file.c -o /a/b/c/file.o --put-object-in-dir-non-existing-option /a1/a2/a3
You can not put /a/b/c/file.o under /a1/a2/a3, since both paths are absolute. Thus "-c" should be changed to name object file only.
I advise you to consider a replacement of makefile, like cmake, scons and other.
This will enable to implement build system as for for simple project as well as for bigger one too.
See for example how it's easy to compile using cmake your example.
Just create file CMakeList.txt in srcdir/:
cmake_minimum_required(VERSION 2.6)
project(test)
add_library(test file1.c file2c file3.c)
And now type:
mkdir -p builddir/objdir
cd builddir/objdir
cmake ../../srcdir
make
That's all, object files will reside somewhere under builddir/objdir.
I personaly use cmake and find it very convinient. It automatically generates dependencies and has other goodies.
I am trying to figure out the same thing. For me this worked
CC = g++
CFLAGS = -g -Wall -Iinclude
CV4LIBS = `pkg-config --libs opencv4`
CV4FLAGS = `pkg-config --cflags opencv4`
default: track
track: main.o
$(CC) -o track $(CV4LIBS) ./obj/main.o
ALLFLAGS = $(CFLAGS) $(CV4FLAGS)
main.o: ./src/main.cpp ./include/main.hpp
$(CC) $(ALLFLAGS) -c ./src/main.cpp $(CV4LIBS) -o ./obj/main.o
``
This is among the problems autoconf solves.
If you've ever done ./configure && make you know what autoconf is: it's the tool that generates those nice configure scripts. What not everyone knows is that you can instead do mkdir mybuild && cd mybuild && ../configure && make and that will magically work, because autoconf is awesome that way.
The configure script generates Makefiles in the build directory. Then the entire build process happens there. So all the build files naturally appear there, not in the source tree.
If you have source files doing #include "../banana/peel.h" and you can't change them, then it's a pain to make this work right (you have to copy or symlink all the header files into the build directory). If you can change the source files to say #include "libfood/comedy/banana/peel.h" instead, then you're all set.
autoconf is not exactly easy, especially for a large existing project. But it has its advantages.
Personally for single files I do this,
rm -rf temps; mkdir temps; cd temps/ ; gcc -Wall -v --save-temps ../thisfile.c ; cd ../ ; geany thisfile.c temps/thisfile.s temps/thisfile.i
temps folder will keep all the object, preprocessed and assembly files.
This is a crude way of doing things and I would prefer above answers using Makefiles.
My system is windows 8.1. I'm working on cygwin 32 bit version (first i set up 64 bit version and could not uninstall completely , later set up 32 bit version).I simply want to use 'make' utility. All my makefiles' extensions are 'makefile'.
When i try this below (to see them work , I only use simple makefiles)
make kernel.o (in shell)
kernel.o : kernel.c
<tab>gcc - ffreestanding -c $< -o $#
it works , and compiles.
But these ones below do not work. And for testing purposes and keeping things simple, each source and corresponding makefiles are in own directory. And all make commands've been made in the current directory where source and corresponding makefiles are located.
All executables (nasm ,ld ,objcopy ,cat) that cygwin needs to run the recipes are in the same directory (that is c:\cygwin\bin\)
If i command the recipes from shell, they work.
I also changed source files to see what would happen.
I also thought that maybe the problem is from cygwin itself , and i set up linux ubuntu desktop version to my machine. But they are (recipes below) not working too.(and also If i command the recipes from shell, they work.)
make kernel_entry.o (in shell)
make: *** No rule to make target 'kernel_entry.o'.
Rule:
kernel_entry.o : kernel_entry.asm
<tab>nasm $< -o $# -f coff (coff for windows)
//--------------------------------
make os-image.bin (in shell)
make: *** No rule to make target 'os-image.bin'.
Rule:
os-image.bin: boot.bin kernel.bin
<tab>cat $< > $#
//--------------------------------
make boot.bin
make: *** No rule to make target 'boot.bin'.
Rule :
boot.bin : boot.asm
<tab> nasm $< -f bin -o $#
*recipes with ld and objcopy also does not work.*
Thank you in advance...
These are my files and directory appearance :
C:\cygwin\bin --> where gcc.stays
C:\cygwin\bin --> where make.exe stays
C:\cygwin\bin --> where objcopy stays
C:\cygwin\bin --> where nasm.exe stays
C:\cygwin\bin --> where ld stays
C:\cygwin\home\me\OS\boot --> where boot.makefile stays and also boot.asm source code
C:\cygwin\home\me\OS\kernel --> where kern.makefile stays ( working sample ) and also kernel.c source code
And this is cygwin shell appearance:
me#Me ~/os/kernel
$ dir
kern.makefile kernel.c kernel_entry.asm
**in my kern.makefile the existing rule is as follows
kernel_entry.o : kernel_entry.asm
nasm $< -o $# -f coff
and boot directory
me#Me ~/os/boot
$ dir
boot.asm disk_load.asm print_hex.asm print_string_pm.asm
boot.makefile gdt.asm print_string.asm switch_to_pm.asm
**in my boot.makefile the existing rule is as follows
boot.bin : boot.asm
nasm $< -f bin -o $#
Make does not see your makefiles.
From the GNU make manual:
If no -f option is present, make will look for the makefiles GNUmakefile, makefile, and Makefile, in that order.
From what I see, your makefiles (kern.makefile, boot.makefile) are simply not found by your call to make (which does not have a -f option). This makes make rely on its internal rules, which do not include any %.o: %.asm dependency or somesuch (for make, assembly ends in .s, assembly with preprocessing to be done in .S).
This can become bloody confusing when your *.c and *.S files are compiled into *.o files, because make does have internal rules for those -- which, of course, stubbornly refuse to take any compiler options into account that you might have defined in that makefile of yours that make doesn't actually read. ;-)
So either call
make -f kern.makefile kernel.o
or (and this is my recommendation), rename <whatever>.makefile to Makefile (which is the canonical way of naming those).
I got the below makefile which works perfectly fine under linux as well as mac os. However it fails to do anything on FreeBSD, and I have no clue why. It gives the following output:
19:31:35 user#host:~/libhttp++/src> make
-
Making HTTP++ library..
make[1]: don't know how to make obj/libhttp++.a. Stop
make[1]: stopped in /usr/home/user/libhttp++/src/obj
*** Error code 2
Stop.
make: stopped in /usr/home/user/libhttp++/src
I also tried gmake, which gives the following output:
19:31:35 user#host:~/libhttp++/src> gmake
-
Making HTTP++ library..
Building Lib ...
ar -rs obj/libhttp++.a obj/html.o obj/http.o obj/object.o
ar: warning: creating obj/libhttp++.a
ar: warning: can't open file: obj/html.o: No such file or directory
ar: warning: can't open file: obj/http.o: No such file or directory
ar: warning: can't open file: obj/object.o: No such file or directory
ar: fatal: Failed to open 'obj/libhttp++.a'
*** Error code 70
Stop.
make[1]: stopped in /usr/home/user/libhttp++/src
gmake: *** [all] Error 1
One issue might be that i'm trying to keep all intermediate object files as well as the lib itself in a separate subdirectory ("obj").
The problem is, I dont know much about makefiles, and the freebsd handbook as well as any example makefiles i could find via google did not help much. The makefile is basically copied from a working linux makefile I found somewhere, and well, it works on linux and mac os. Is there a way to convert it to a format which works on all 3 platforms? any help would be much appreciated.
makefile:
#--------------------------------------------------------------------------
# defines
#--------------------------------------------------------------------------
LIBDIR = ../lib
INCDIR = ../include
OBJDIR = obj
CXX = g++
doLib = ar -rs
doCompile = $(CXX) $(CXXFLAGS)
doLink = $(CXX) $(LFLAGS)
doClean = rm -f *.o *~ *.a
#--------------------------------------------------------------------------
# Library
#--------------------------------------------------------------------------
OBJECTS = $(OBJDIR)/html.o \
$(OBJDIR)/http.o \
$(OBJDIR)/object.o
LIBXMLPATH=~/Development/libxml2_2
LIBCURLPATH=~/Development/libcurl
#CDEF += -D__FORIOS__
CXXFLAGS ?= -I ./ -I $(LIBXMLPATH)/include -I $(LIBCURLPATH)/include/curl $(CDEF) -c -ggdb -Wreturn-type -Wformat -pedantic -Wunused-variable -Wunused-label -Wunused-value -Wno-long-long
DISTLIB = http++
#--------------------------------------------------------------------------
# compile lib objects
#--------------------------------------------------------------------------
lib: all
all:
#(echo -; echo Making HTTP++ library..; make $(OBJDIR)/lib$(DISTLIB).a)
$(OBJDIR)/lib$(DISTLIB).a: $(OBJECTS)
#echo Building Lib ...
$(doLib) $# $(OBJECTS)
clean:
#(echo Cleanup HTTP++ library)
$(doClean)
(cd $(OBJDIR); $(doClean))
install:
#(echo Installing HTTP++ library in ../include ../lib)
(mkdir -p $(LIBDIR); mkdir -p $(INCDIR))
(cp -p *hpp *h $(INCDIR)/ ; cp -p $(OBJDIR)/lib$(DISTLIB).a $(LIBDIR)/)
#--------------------------------------------------------------------------
# Compiler Call
#--------------------------------------------------------------------------
$(OBJDIR)/%.o: %.cc
#echo Compile "$(*F)" ...
$(doCompile) $(*F).cc -o $#
#--------------------------------------------------------------------------
# dependencies
#--------------------------------------------------------------------------
CHECK = def.h
$(OBJDIR)/html.o : html.cc $(CHECK) html.hpp
$(OBJDIR)/http.o : http.cc $(CHECK) http.hpp
$(OBJDIR)/object.o : object.cc $(CHECK) object.hp
GNU make has a number of extensions beyond the make on BSDs (which is sometimes available on non-BSD boxes as bsdmake). You can look at the FreeBSD man page for make to see the differences, but the most salient one is that the syntax
%.target: %.source
is only available on GNU make (there's a similar syntax, though less flexible, in BSD make).
I'd have thought that gmake would work, though. Hmm...
Looking at the makefile, I can't see anything that creates $(OBJDIR), so it might be that that's the problem – it's the first thing I'd try to fix, at any rate. If so, then just mkdir obj beforehand might work.
Yesterday I found the problem:
all:
#(echo -; echo Making HTTP++ library..; make $(OBJDIR)/lib$(DISTLIB).a)
This line is bad when the makefile is used with gmake, because it calls make instead of gmake. So the fix is:
all:
#(echo -; echo Making HTTP++ library..; gmake $(OBJDIR)/lib$(DISTLIB).a)
Now it works perfectly without any adjustments when using gmake.
i am new to makefiles and have just rescently created a makefile that works for a c++ project. it has two cpp files and one h file. i am trying to convert my file to work in linux but cant seem to figure out how. any ideas?
EXE = NumberGuessingGame.exe
CC = cl
LD = cl
OBJ = game.obj userInterface.obj
STD_HEADERS = header.h
CFLAGS = /c
LDFLAGS = /Fe
$(EXE): $(OBJ)
$(LD) $(OBJ) $(LDFLAGS)$(EXE)
game.obj: game.cpp $(STD_HEADERS)
$(CC) game.cpp $(CFLAGS)
userInterface.obj: userInterface.cpp $(STD_HEADERS)
$(CC) userInterface.cpp $(CFLAGS)
#prepare for complete rebuild
clean:
del /q *.obj
del /q *.exe
For in depth treatment of make on Linux, see GNU make.
There are a few differences. Binaries have no extension
EXE = NumberGuessingGame
The compiler is gcc, but need not be named, because CC is built in, same goes for LD. But since your files are named .cpp, the appropriate compiler is g++, which is CXX in make.
Object files have extension .o
OBJ = game.o userInterface.o
STD_HEADERS = header.h
Compiler flags
CXXFLAGS = -c
The equivalent for /Fe is just -o, which is not specified as LDFLAGS, but spelled out on the linker command line.
Usually, you use the compiler for linking
$(EXE): $(OBJ)
$(CXX) $(LDFLAGS) $(OBJ) -o $(EXE)
You don't need to specify the rules for object creation, they are built in. Just specify the dependencies
game.o: $(STD_HEADERS)
userInterface.o: $(STD_HEADERS)
del is called rm
clean:
rm -f $(OBJ)
rm -f $(EXE)
One important point is, indentation is one tab character, no spaces. If you have spaces instead, make will complain about
*** missing separator. Stop.
or some other strange error.
You can also use CMake to accomplish your task:
Put following into CMakeLists.txt file in the root directory of your project (<project-dir>):
cmake_minimum_required (VERSION 2.6)
project (NumberGuessingGame)
add_executable(NumberGuessingGame game.cpp serInterface.cpp)
Then on the console do
"in-source" build
$ cd <project-dir>
$ cmake .
$ make
or "out-source" build
$ mkdir <build-dir>
$ cd <build-dir>
$ cmake <project-dir>
$ make
You can adjust build setting using nice GUI tool. Just go to the build directory and run cmake-gui.
You don't need to include headers in the dependency list. The compiler will fail on its own, stopping make from continuing. However, if you're including them in the dependency list to force make to rebuild files in case the header changes, nobody will stop you.
CFLAGS never needs to contain -c, nor does LDFLAGS need -o. Below is a revamped makefile. Note that you can always override a macro explicitly defined in a makefile or implicitly defined using something like make CFLAGS=-Wall for example. I used the de facto standard CXX macro name in the event that you have C source files, which must be compiled using a C compiler (the value of the CC macro) instead of a C++ compiler.
.POSIX:
#CC is already implicitly defined.
CXX = g++
OBJ = game.o userInterface.o
STD_HEADERS = header.h
.SUFFIXES:
.SUFFIXES: .o .cpp .c
NumberGuessingGame: $(OBJ) $(STD_HEADERS)
$(CXX) $(CFLAGS) -o $# $(OBJ) $(LDFLAGS)
.cpp.o: $(STD_HEADERS)
$(CXX) $(CFLAGS) -c $<
#There is already an implicit .c.o rule, thus there is no need for it here.
#prepare for complete rebuild
clean:
-rm -f NumberGuessingGame *.o
As yegorich answered, you can use a build system like Cmake. It is much more flexible, cross-platform, and can generate Unix Makefiles as well as Nmake Makefiles and Visual Studio solutions on Windows.