I have a makefile. When I run it on Unix I get this error:
cc -I/opt/oracle/product/9.2.0/rdbms/demo -I/opt/oracle/product/9.2.0/rdbms/public \
-I/opt/oracle/product/9.2.0/plsql/public \
-I/opt/oracle/product/9.2.0/network/public -I../common -I../include -I. \
-L/opt/oracle/product/9.2.0/lib -L/opt/oracle/product/9.2.0/rdbms/lib -L../../lib \
-g -errwarn=%all -Xt -lclntsh -ldl -Bstatic -lclient9 -lvsn9 -lcommon9 -lgeneric9 \
-lmm -lcore9 -lnls9 -lwssmbx -ldes -lnsl -lsocket -lgen -lm -o bessToWss
usage: cc [ options] files. Use 'cc -flags' for details
*** Error code 1
What does "usage: cc [ options] files. Use 'cc -flags' for details" mean?
I'm not sure why I get the error because I do use cc -flags:
$(TARGET_DIR)/bessToWss: $(INTFOBJS)
cc $(CFLAGS) $(INTFOBJS) $(OCISHAREDLIBS) -o $#
EDIT: Adding my entire makefile
ORACLE_HOME=/opt/oracle/product/9.2.0
COMMON_SRC=../common
BNS_INCLUDE=../include
LIBHOME=$(ORACLE_HOME)/lib/
RDBMSLIB=$(ORACLE_HOME)/rdbms/lib/
WSSLIBS =-lwssmbx -ldes
LLIBRDBMS_CLT =-lclient9 -lvsn9 -lcommon9 -lgeneric9 -lmm
LLIBCLNTSH =-lclntsh -ldl
CORELIBS =-lcore9 -lnls9
LDLIBS =-lnsl -lsocket -lgen -lm
EXSYSLIBS =-R $(ORACLE_HOME)/lib
STATICTTLIBS =$(LLIBRDBMS_CLT) $(CORELIBS) $(WSSLIBS) $(LDLIBS)
OCISHAREDLIBS =$(LLIBCLNTSH) -Bstatic $(STATICTTLIBS)
LDFLAGS =-L$(ORACLE_HOME)/lib -L$(ORACLE_HOME)/rdbms/lib -L../../lib
INCLUDE =-I$(ORACLE_HOME)/rdbms/demo -I$(ORACLE_HOME)/rdbms/public -I$(ORACLE_HOME)/plsql/public -I$(ORACLE_HOME)/network/public -I$(COMMON_SRC) -I$(BNS_INCLUDE) -I.
CFLAGS =$(INCLUDE) $(LDFLAGS) -g -errwarn=%all -Xt
BESSOBJS=bessToWss.o
COMMONLIST=$(COMMON_SRC)/oracle.c \
$(COMMON_SRC)/logger.c
INTFOBJS=$(BESSOBJS) $(COMMONLIST)
$(TARGET_DIR)/bessToWss: $(INTFOBJS)
cc $(CFLAGS) $(INTFOBJS) $(OCISHAREDLIBS) -o $#
clean:
$(RM) *.o
It means you have an invalid compiler option on the command line. It might be that you are using the 'wrong' compiler (maybe GCC instead of Sun's compiler, for example). The probable problem options I see are:
-Xt
-errwarn=%all
and maybe (but probably not)
-Bstatic
The others would not lead to usage errors like that.
(NB: It would help to identify the machine and the compiler you are using, and the compiler Oracle expects you to use.)
It looks like you don't have any object files to actually link together. The $(INTFOBJS) variable is likely empty. Along with potentially having the wrong flags, this would also cause it to fail.
Related
I am trying to successful execute a make file that comes from a new crytpo-coin called Sia Coin. It can be found here Sia Coin GPU Miner. It's relatively new and so some stuff requires more manual installation. I was getting the following error on Ubuntu 16.04 when using the make file. CL/cl.h was missing, and I was able to install and it is located at /usr/include/nvidia-361/CL/cl.h. However, when I ran the make file I still get errors so I think I need to include this path someone in the Make file, the problem is I am not familiar with make files at all. Below is the Make file I need to edit to include the path for compilation:
ifeq ($(shell uname -s),Darwin)
CC ?= clang
LDLIBS += -lcurl -framework OpenCL
else
CC ?= gcc
LDLIBS += -lOpenCL -lcurl
endif
CFLAGS += -c -std=c11 -Wall -pedantic -O2
TARGET = sia-gpu-miner
SOURCES = sia-gpu-miner.c network.c
OBJECTS = $(patsubst %.c,%.o,$(SOURCES))
all: $(TARGET)
%.o: %.c
$(CC) $(CFLAGS) -o $# $<
$(TARGET): $(OBJECTS)
$(CC) -o $# $^ $(LDLIBS)
clean:
rm -f $(TARGET) $(OBJECTS)
.PHONY: all clean
Any help toward solving this problem is greatly appreciated.
Edit:
A new message I am getting now adding
CFLAGS += -c -std=c11 -Wall -pedantic -O2 -I /usr/include/nvidia-361
is now:
-lOpenCL -lcurl /usr/bin/ld: cannot find -lOpenCL collect2: error: ld returned 1 exit status
Two files did compile:
sia-gpu-miner.c
network.c
But I don't know enough to know why the -lOpenCL is not found. No ld directory exists in that directory location in the error if that helps.
Try changing
CFLAGS += -c -std=c11 -Wall -pedantic -O2
to
CFLAGS += -c -std=c11 -Wall -pedantic -O2 -I /usr/include/nvidia-361
I have 6 programs: HOSpital.c, GenPazienti.c, Triage.c, Paziente.c, Prestazione.c and Reparto.c.
No one of them includes any other.
How can i do the makefile?
I tried with:
all: HOSpital GenPazienti Paziente Prestazione Reparto Triage
HOSpital: HOSpital.o
gcc -o HOSpital HOSpital.c
HOSpital.o: HOSpital.c
gcc -c HOSpital HOSpital.c
GenPazienti: GenPazienti.o
gcc -o GenPazienti GenPazienti.c
GenPazienti.o: GenPazienti.c
gcc -c GenPazienti GenPazienti.c
Paziente: Paziente.o
gcc -o Paziente Paziente.c
Paziente.o: Paziente.c
gcc -c Paziente Paziente.c
Prestazione: Prestazione.o
gcc -o Prestazione Pretazione.c
Prestazione.o: Prestazione.c
gcc -c Prestazione Prestazione.c
Reparto: Reparto.o
gcc -o Reparto Reparto.c
Reparto.o: Reparto.c
gcc -c Reparto Reparto.c
Triage: Triage.o
gcc -o Triage Triage.c
Triage.o: Triage.c
gcc -c Triage Triage.c
clean:
rm -f *.o
But if i change something and i type "make" i get the error:
"Program_name: linker input file unused because linking not done"
Lets take a single example:
gcc -c HOSpital HOSpital.c
This will attempt to use HOSpital as an input file.
Either use the correct option to name the output file, -o, and name it correctly. Like in
gcc -c -o HOSpital.o HOSpital.c
Or don't specify the output file name at all, then the compiler will use the input source file and change the .c suffix to .o. Like in
gcc -c HOSpital.c
It's the same problem all over.
Not that it matters in the end, the rule is used so the object file will be built, but you don't actually use the object file:
gcc -o HOSpital HOSpital.c
Here you use the source file directly to create the program. I think you meant to use
gcc -o HOSpital.o HOSpital.o
And as with the previous problem, you make this mistake all over.
Finally some general tips.
First, build with more warnings enabled. It will help you in the long run to find mistakes in the code, and will help find out places where there's possible undefined behaviors. I recommend at least adding -Wall -Wextra -pedantic.
Then you don't need to list all the object files and their rules explicitly in the makefile. The make program already knows how to make e.g. object files through implicit rules.
That last point means you can shorten down the makefile to something like
CFLAGS = -Wall -Wextra -pedantic -pipe
LD = gcc
LDFLAGS = -pipe
HOSpital: HOSpital.o
$(LD) $(LDFLAGS) -o $# $^
GenPazienti: GenPazienti.o
$(LD) $(LDFLAGS) -o $# $^
Paziente: Paziente.o
$(LD) $(LDFLAGS) -o $# $^
Prestazione: Prestazione.o
$(LD) $(LDFLAGS) -o $# $^
Reparto: Reparto.o
$(LD) $(LDFLAGS) -o $# $^
Triage: Triage.o
$(LD) $(LDFLAGS) -o $# $^
clean:
-rm -f *.o
The variable $# is the target of the rule, and the variable $^ is all prerequisites. For e.g.
HOSpital: HOSpital.o
the variable $# is HOSpital and $^ is HOSpital.o.
I am trying to compile a C language library as a shared object on my new install of Fedora 22. The project compiled fine on my old install of Fedora 20. But now, when I run my makefile:
CC=gcc
vpath %.c src
vpath %.h inc
CFLAGS = -fPIC
INCLUDE = -Iinc -I/usr/include -I/usr/local/include
LIBPATH = -L/usr/lib -L/lib64
LIBS = -lportaudio -lm -lpthread -ldl
OBJ_PATH = ./objs
SRCS = my_code1.c my_code2.c # etc.
OBJS = $(SRCS:.c=.o)
.PHONY: libmylib.so
all: libmylib.so
debug: $(CFLAGS) += -DDEBUG -O0 -g3 -DPD
debug: all
release: $(CFLAGS) += -DTESTING -O2 -DPD -funroll-loops -fomit-frame-pointer
release: all
%.o: %.c
$(CC) $(CFLAGS) $(INCLUDE) $(LIBPATH) $(LIBS) -c -o $# $^
libmylib.so: $(OBJS)
$(CC) -shared -Wl,-soname,libmylib.so \
-Wl,--no-undefined $(OBJS) -lc -lportaudio -ldl -lm -lpthread
mv libmylib.so ./bin
mv *.o $(OBJ_PATH)
clean:
rm $(OBJ_PATH)/*.o
rm bin/libmylib.so
I get very many undefined reference errors:
my_code1.o: In function `func_in_my_code1':
my_code1.c:(.text+0x1b8): undefined reference to `func_from_my_code2'
my_code2.o: In function `func_in_my_code2':
my_code2.c:(.text+0x310): undefined reference to `func_from_my_func1'
The functions in question are most certainly defined in the code. Presumably these are compiled into .o files in the compile stage.
The exact same build environment worked on my previous fedora installation. I am at a loss as to why I should get these errors.
Also, if I compile without the -Wl,--no-undefined flag, it compiles fine, but when I try to load the library from another application, it tosses the same set of undefined errors.
This may have nothing to do with the new version of Fedora. It is possible that there are some environment variables or something that didn't make through to my new install, but I have no idea what they could be.
Apparently I now need to insert the extern keyword into these functions. The code compiled and ran perfectly well before... I would like to reiterate, for posterity's sake, that I did post the entire makefile in my question.
So I tried to recompile one of my projects from a few weeks ago and to my surprise I keep receiving an error one on it. I used MinGW to compile it originally and Eclipse CDT. I have -Wall flag enabled on GCC so I assumed if it was a problem with the code I would have a more useful information than a make error 1 being thrown. As such, I suspect that the issue could lie in how I formatted the make file. Luckily, I did compile the project when I push the commits last time and the binaries are still in the repo. Nevertheless, I would appreciate some help so that I can continue to improve
the project.
Edit: when I do -all, it just refuses to compile.
Here is the makefile. I hope it is a simple as me following some incorrect syntax:
CC=gcc -I../Include -L..\Lib
override CFLAGS+=-Wall -O3 #$(shell pkg-config --cflags fftw3)
#override LDFLAGS+=#$(shell pkg-config --libs fftw3 glib-2.0) -lm
.PHONY: all clean
all: lvdoenc lvdodec
lvdoenc: lvdoenc.o lvdomain.o
$(CC) $(CFLAGS) -o $# $^ $(LDFLAGS) -I../Include -L../Lib -lfftw3
lvdodec: lvdodec.o lvdomain.o
$(CC) $(CFLAGS) -o $# $^ $(LDFLAGS) -I../Include -L../Lib -lfftw3
%.o: %.c
$(CC) -c $(CFLAGS) -o $# $^
lvdoenc.c: lvdocommon.h
lvdodec.c: lvdocommon.h
clean:
rm -f lvdoenc lvdodec lvdomain.o lvdoenc.o lvdodec.o
Here is a link to my repo:
https://github.com/Skylion007/LVDOWin
Update: Using some of the answers I have confirmed that it is GCC that is exiting with an error 1 and I cannot figure out why.
Update2: It's not printing anything to syserr.
Without a transcript of make's output, when you run it, I can't see why GCC should fail silently, but I can see at least two problems with your makefile:
Since you state that you are using MinGW, your target platform must be MS-Windows, on which executable files should be qualified by a .exe extension; thus, your all: lvdoenc lvdodec rule is malformed; it should, at the very least be all: lvdoenc.exe lvdodec.exe[1], (or better, for portability all: lvdoenc$(EXEEXT) lvdodec$(EXEEXT), where you define EXEEXT = .exe for Windows, and leave EXEEXT undefined, or defined to be nothing, for platforms which don't require the extension).
Your two rules lvdoenc.c: lvdocommon.h and lvdodec.c: lvdocommon.h are obviously incorrect; the .c files don't depend on the .h, but their respective .o files do. Thus, these two rules should be lvdoenc.o: lvdocommon.h and lvdodec.o: lvdocommon.h respectively.
[1] Of course, you then also need to correctly refer to these two "goals" respectively, as lvdoenc.exe and lvdodec.exe, (or lvdoenc$(EXEEXT) and lvdodec$(EXEEXT)), consistently, throughout the makefile.
There are a few other constructs, within your makefile, which I consider questionable: CC shouldn't really be defined, with the -I../Include or -L..\Lib, (and why inconsistently / in the former, but \ in the latter? Both should be /). Conventionally, -I ... belongs in CPPFLAGS, and -L ... in LDFLAGS, with both CFLAGS and CPPFLAGS passed to the compiler, and normally all of CFLAGS, CPPFLAGS, and LDFLAGS passed to the compiler driver, when invoking the linker, (although, as others have noted in comments, the -I ... settings are strictly necessary when compiling .c to .o, while the -L ... settings are required only in the linking phase).
the following makefile is more in line with what you need for your project.
However, it does not use:
#$(shell pkg-config --libs fftw3 glib-2.0)
which you will need to re-add.
notice the usage of ':=' when defining macros, so the macro only needs to be evaluated once, rather than every time it is referenced.
the paths for the SHELL macro and the CC macro may need to be modified for your system.
SHELL := /usr/bin/sh
CC := /usr/bin/gcc
#CFLAGS := -c -Wall -Wextra -pedantic -std=c99 -O3 #$(shell pkg-config --cflags fftw3)
CFLAGS := -c -Wall -Wextra -pedantic -std=c99 -O3
# override LDFLAGS+=#$(shell pkg-config --libs fftw3 glib-2.0) -lm
LDFLAGS :=
SRCS := $(wildcard *.c)
ENCOBJS := lvdoenc.o lvdomain.o
DECOBJS := lvdodec.o lvdomain.o
.PHONY: all clean
all: lvdoenc lvdodec
lvdoenc: $(ENCOBJS)
$(CC) $(LDFLAGS) -o $# $(ENCOBJS) -L../Lib -lfftw3 -lm
lvdodec: $(DECOBJS)
$(CC) $(LDFLAGS) -o $# $(DECOBJS) -L../Lib -lfftw3 -lm
%.o:%.c lvdocommon.h
$(CC) -c $(CFLAGS) -c $< -o $# -I../Include
clean:
rm -f lvdoenc lvdodec lvdomain.o lvdoenc.o lvdodec.o
Apparently, all that was the cause was that I had uninstalled the 64bit version of MinGW and tried to switch to the 32bit version of MinGW. Unfortunately, some of the libraries would not compile in the 32bit version so I just used MinGW-w instead to solve this problem. It turns out GCC was not starting due to a linker error, but this error was not proportionating and could not be discovered until I tried to run it from the Windows terminal. I am still in the process of solving it and will update this answer when I have fully solved the issue.
Had the same problem while tried to compile my project with make from MSys. Accidentally problem had been solved, after I added a quotes to gcc input and output files in the makefile. I don't know how it works, but hope that it will help someone else.
So in the TS example code should look like this
%.o: %.c
$(CC) -c $(CFLAGS) -o "$#" "$^"
PS: had no problems with building project from ubuntu terminal though, so maybe it's just a msys problem.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Linker errors when compiling against glib…?
Okay, I know this may be a duplicate, but I can't find any other answer to my problem.
I am trying to install Pintos and when I run 'make' in the src/utils directory, I get the error that there is an undefined reference to 'floor'. I checked the makefile and here's what I got:
all: setitimer-helper squish-pty squish-unix
# 2207718881418
CC = gcc
CFLAGS = -Wall -W
LDFLAGS = -lm
setitimer-helper: setitimer-helper.o
squish-pty: squish-pty.o
squish-unix: squish-unix.o
clean:
rm -f *.o setitimer-helper squish-pty squish-unix
I tried adding LIBS = -lm but that didn't help.
Output of make:
gcc -lm setitimer-helper.o -o setitimer-helper
setitimer-helper.o: In function `main':
setitimer-helper.c:(.text+0xbb): undefined reference to `floor'
collect2: ld returned 1 exit status
make: *** [setitimer-helper] Error 1
Any solutions to this dilemma?
Your original makefile defines a bunch of variables
CC = gcc
# etc
and lists some dependencies
setitimer-helper: setitimer-helper.o
# etc
but doesn't have any recipes giving the exact commands to be used to remake the targets, except for the clean rule. This means that built-in implicit rules will be used; e.g., to link setitimer-helper the following built-in rule will be used:
$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $#
For setitemer-helper, the automatic variables are filled in using the relevant dependency:
$(CC) $(LDFLAGS) setitimer-helper.o $(LDLIBS) -o setitimer-helper
and from this you can see how the remaining variables -- $(CC), $(LDFLAGS), and $(LDLIBS) -- were filled in to give the output of make that you saw.
As various people have noted, you need to make sure that -lm goes at the end of the link command so that it can be used to satisfy references to library functions like floor(). At the moment, your makefile sets $(LDFLAGS) to -lm, but that variable is used at the start of the link command.
The conventional variables are set up in this built-in rule so that LDFLAGS can be used for options (a.k.a. "flags") that (historically) need to be at the start of the link command, and LDLIBS can be used for libraries that need to be specified after the *.o object files.
So to fix this in terms of the makefile you are using, you need to remove -lm from the LDFLAGS variable that is defined, and instead add another variable definition for LDLIBS:
LDLIBS = -lm
(I'm oversummarising slightly: the built-in rule also contains $(TARGET_ARCH) and $(LOADLIBES), but those aren't of interest here.)
It's compiled in wrong order, the way to proceed is:
CC = gcc
CFLAGS = -Wall -W
LDFLAGS = -lm
myprog: myprog.o more_code.o
${CC} ${CFLAGS} myprog.o more_code.o ${LDFLAGS} -o myprog
myprog.o: myprog.c
${CC} ${CFLAGS} -c myprog.c
more_code.o: more_code.c
${CC} ${CFLAGS} -c more_code.c
clean:
\rm myprog.o more_code.o myprog
More info: http://www.physics.utah.edu/~p5720/rsrc/make.html
Can you show me in terms of the original makefile?
I can try :)
CC = gcc
CFLAGS = -Wall -W
LDFLAGS = -lm
OBJECTS = setitimer-helper.o squish-pty.o squish-unix.o
all: setitimer-helper
setitimer-helper: $(OBJECTS)
${CC} ${CFLAGS} $(OBJECTS) ${LDFLAGS} -o setitimer-helper
setitimer-helper.o: setitimer-helper.c
${CC} ${CFLAGS} -c setitimer-helper.c
squish-pty.o: squish-pty.c
${CC} ${CFLAGS} -c squish-pty.c
squish-unix.o: squish-unix.c
${CC} ${CFLAGS} -c squish-unix.c
And since you are new to Makefile, it's a good idea to add -Wextra -pedantic to CFLAGS