I need some help.
I worked on a C project locally and it ran perfect with no issues at all.
Then I moved my whole project files to a linux server (using Bitwise) and ran it using the following command:
gcc -g -std=c99 -Wall -pedantic-errors -Werror -DNDEBUG main.c map.c map.h utilities.c
utilities.h election.c election.h extended_map.c extended_map.h test_utilities.h -o outmap
and again everything worked as expected.
Now, I want to replace my version of test_utilities.h with the version saved on that server, so I opened main.c (which is the only file to include test_utilities.h and replaced:
#include "test_utilities.h"
with
#include "~mtm/public/1920b/ex1/test_utilities.h"
But the terminal shows me the following error:
gcc: error: test_utilities.h: No such file or directory
-bash-4.2$
As suggested I changed it to
gcc -g -std=c99 -Wall -pedantic-errors -Werror -DNDEBUG main.c map.c map.h utilities.c utilities.h election.c election.h extended_map.c extended_map.h test_utilities.h -o outmap -I ~mtm/public/1920b/ex1/
But still I get the following:
gcc: error: test_utilities.h: No such file or directory
update2: (I was requested to remove .h files so now I got)
gcc -g -std=c99 -Wall -pedantic-errors -Werror -DNDEBUG main.c map.c utilities.c election.c extended_map.c -o outmap
Writing ~mtm to refer to the home directory of user mtm is a shortcut that your shell understands. It isn't something that the C preprocessor understands. So you'll have to spell it out as /home/mtm (or wherever mtm's home directory is located) instead of ~mtm.
That said, a better way would be to just leave it as "test_utilities.h" and instead adjust the include path of the compiler (specified via -I when invoking the compiler) to include ~mtm/public/1920b/ex1/.
You also shouldn't specfiy test_utilities.h as an argument to the compiler. In fact none of the header files should be passed as arguments to the compiler.
Related
I'm working on a C clone of the 2048 game, using curses.h for the UI. When trying to compile it with Cygwin using the make commanad, I get following message:
PS D:\C\ps3> make all
gcc -std=c11 -Wall -Werror -g -c main.c -lm -lcurses -o main.o
main.c:4:20: fatal error: curses.h: No such file or directory
#include <curses.h>
^
compilation terminated.
make: *** [Makefile:13: main.o] Error 1
So I ran the setup again, looking for any package that has "curses" in it's name and installed it, added my /bin folder to the PATH variable but it didn't help.
I'm working on a 64-bit Win10 and trying to compile the program with Cygwin's terminal, using a Makefile. file. I've tried reinstalling the packages with curses in their name multiple times with no help.
Part of my Makefile:
CC=gcc
CFLAGS=-std=c11 -Wall -Werror -g
LDLIBS=-lm -lcurses
OUTPUT=game
# targets
all: $(OUTPUT)
$(OUTPUT): k.o hof.o main.o
$(CC) $(CFLAGS) k.o hof.o main.o $(LDLIBS) -o $(OUTPUT)
main.o: main.c
$(CC) $(CFLAGS) -c main.c $(LDLIBS) -o main.o
The line in main.c the error is pointing to:
#include "hof.h"
#include "k.h"
#include "ui.h"
#include <curses.h>
The header file would be in libncurses-devel (perhaps overlooked). Here's a screenshot showing the "curses" packages which I have in my local repository:
I'm trying to compile code from a backtrace project https://code.google.com/p/backtrace-mingw/ which is written for MinGW, but using MinGW-w64.
My old install and fresh install of MinGW-w64 produce the same problem. Path is set in path variables, and also in command prompt:
C:\mingw-w64\i686-4.9.2-win32-sjlj-rt_v3-rev1\mingw32\bin
and C:\mingw-w64\i686-4.9.2-win32-sjlj-rt_v3-rev1\mingw32 although this one isn't needed.
This is the makefile of that project:
.PHONY: all clean
all : backtrace.dll test.exe
backtrace.dll : backtrace.c
gcc -O2 -shared -Wall -o $# $^ -lbfd -lintl -liberty -limagehlp
test.exe : test.c
gcc -g -Wall -o $# $^
clean :
-del -f backtrace.dll test.exe
When compiling I get the warning:
backtrace.c:23:17: fatal error: bfd.h: No such file or directory #include < bfd.h>`
Which is weird because that file exists in ../mingw32/include folder.
If I add this when compilind the dll: -IC:\mingw-w64\i686-4.9.2-win32-sjlj-rt_v3-rev1\mingw32\include it continues but stops at the directive: #error config.h must be included before this header and config.h is missing in MinGW-w64
Any ideas?
That path is definetely missing from gcc include paths in mingw. I don't know why. You have to add it yourself in any way you like: cmake recipe, autoconf recipe, CFLAGS, CPATH, gcc specs.
And, as far as I remember, it uses only HAVE_STRINGIZE macro from config.h and it is used only to define CONCAT4 macro, that's not used anywhere in bfd.h. So, it's safe to cheat a little and put
#define PACKAGE package
before including bfd.h
add this to the end of the compile statement:
-I./mingw32/include
so the whole compile statement would be:
gcc -g -Wall -o $# $^ -I./mingw32/include
so the compiler knows where to find the include files
So given three files:
main.h
#include <stdio.h>
void printFunc(*char);
main.c
#include "main.h"
int main(){
printFunc("Hello World\n");
return 0;
}
printFunc.c
#include "main.h"
void printFunc(char *string){
printf("%s", string);
return;
}
You can compile using gcc on a linux machine as follows:
gcc -g -Wall -c file1.c //compile but do not link file
gcc -g -Wall -c file2.c //same
gcc file1.o file2.o -o main //executable "main"
or
gcc -g -Wall file1.c file2.c -o main
But I am concerned with how the header file gets included. I came across this when I was working on creating a "makefile" when I noticed that some tutorials will do something like this:
main : main.o printFunc.o
gcc -o main main.o printFunc.o
main.o : main.c
gcc -g -Wall -c -o main.o main.c
printFunc.o : printFunc.c
gcc -g -Wall -c -o printFunc.o printFunc.c
and others will include the header file as a dependent with:
main : main.o printFunc.o //main.h EDIT
//commands
main.o : printFunc.o main.h
//commands
Finally:
So, is it necessary to include the header file as a dependent to the executable? When does the include file get placed within the sources?
And also one could use this command:
executableName : dependencies.o //and a header file?
gcc -g -Wall -o executableSource.c
Which could be done with the line:
gcc -g -Wall -o executableName executableSource.c
Will the second command be run but the first is shorthand notation?
And finally, I thought the "-o" command was "send output to", if you will. If that way, it seems intuitive to run the command like:
gcc compileThisFile andSendOutputTo thisExecutableFile
gcc someSource.c -o executableFile
But with the notation listed above its more like:
gcc sendOutputTo thisExecutableFile fromThisSource
Is that correct?
main : main.o printFun.o main.h is definitely wrong. That's saying that the header is a prerequisite for linking. A header is a prerequisite for compilation.
Assuming what you really meant was to specify the header as a compilation dependency (e.g. printFunc.o : printFunc.c printFunc.h), this means that if the header changes, the object file will be automatically regenerated. If you don't, then it won't.
A dependency in Makefile is saying that whenever any of the listed files change, run the command again. It does not mean that the listed file will be included into the compilation or linking. You still need the regular #include "main.h" in your sources.
Thus, this works too:
printFunc.o : printFunc.c someReadmeFile.txt
gcc -g -Wall -c -o printFunc.o printFunc.c
Whenever printFunc.c or someReadmeFile.txt is updated, gcc -g -Wall .... will be executed again.
I hope it's clearer now.
I have a project that has three files. The main file is called login.c.
I want to #include my other two files using make, but I'm having trouble doing so.
Thanks in advance for any advice!!
here is my makefile:
objects = login.o cipher.o linked.o
coptions = -Wall -g -ggdb
loginTest: ${objects}
gcc ${coptions} -o loginTest ${objects}
login.o: login.c cipher.h linked.h
gcc -c ${coptions} login.c
cipher.o: cipher.c cipher.h
gcc -c ${coptions} cipher.c
linked.o: linked.c linked.h
gcc -c ${coptions} linked.c
the error I get:
make: *** No rule to make target `cipher.h', needed by `login.o'. Stop.
the files in my current working directory:
cipher.c
linked.c
linked.o
login.c
makefile
make can not automatically create *.h.
You need to create it and #include that *.h file by yourself.
I have one directory and underneath it 4 subdirectories like so:
myDir:
myDir/Part1
myDir/Part2
myDir/Part3
myDir/shared
I want to make an executable that takes files from shared, links it to files in Part2 and puts the executable in myDir.
This is what I tried (only the lines in the makefile that are relevant):
Shared/helper.o:
gcc -ansi -pedantic-errors -c -Wall -Werror -g -o Shared/helper.o Shared/helper.c
and above it in the makefile:
Part2/part2code.o: ../Shared/helper.o
gcc -ansi -pedantic-errors -c -Wall -Werror -g -o Part2/part2code.o Part2/part2code.c
and above it in the makefile:
part2code: Part2/part2code.o ../Shared/helper.o
gcc -ansi -pedantic-errors -Wall -Werror -g -lm -o part2code Part2/part2code.o ../Shared/helper.o
(I also tried without the ../ before Shared)
I get this error:
No such file or directory.
help?
Thanks!
In this context, paths in filenames are all relative to where the makefile is. So e.g. Part2/part2code.o: ../Shared/helper.o is incorrect; it should simply be Part2/part2code.o: Shared/helper.o (and so on). Note also that you've written Shared in your makefile, but you've listed your directory as shared...
Although actually, that's still wrong. Rules such as a: b express that b is a prerequisite of a; i.e. that you cannot make a until you've made b. That is not the case for your object files; they don't depend on each other. Usually, an object file depends purely on its constituent source files (*.c and *.h). So, for example, your rule for part2code.o might be something like:
Part2/part2code.o: Part2/part2code.c
gcc -ansi -pedantic-errors -c -Wall -Werror -g -o $# $^
(Note the use of the special variables $# and $^, which substitute in for the target and the prerequisites, respectively.)