0

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.

Skylion
  • 2,696
  • 26
  • 50
  • Possibly the same issue as in http://stackoverflow.com/q/4034392/2564301? – Jongware Jun 13 '15 at 17:51
  • Thanks for the quick response, but I am curious where in my file I would insert the - – Skylion Jun 13 '15 at 17:56
  • The answer provides a link. Maybe should try to first find out what step is causing the error, rather than trying to suppress it. – Jongware Jun 13 '15 at 17:58
  • It appears to be GCC, but that makes no since -Wall should have it print out an errors in compilation right? I also have GDB installed via MinGW if that is of any help. – Skylion Jun 13 '15 at 17:59
  • So I could be mistaken but I added a - and while I no longer get the error 1, the make file is not compiling the target likely because GCC is crashing. – Skylion Jun 13 '15 at 18:19
  • 1) the linker uses parameters in the order given. 2) the '-I../Include' parameter must be on the compile rule, not on the link rule – user3629249 Jun 13 '15 at 18:20
  • possible duplicate of [make: \*\*\* \[ \] Error 1 error](http://stackoverflow.com/questions/5535548/make-error-1-error) – набиячлэвэли Jun 13 '15 at 18:21
  • these two lines: 'lvdoenc.c: lvdocommon.h lvdodec.c: lvdocommon.h' are defining targets that depend on the 'lvdocommon.h' file. However, there is no rule, default or otherwise, of how to use a .h file to produce a .c file. And actually, the .c files should already exist, so those rules will be ignored or /errors/ – user3629249 Jun 13 '15 at 18:22
  • @user3629249 Huh? The lvdocommon.h should not produce a .c file if I am understanding you correctly. According the repo I tried to cross compile this from, they did something similar and it compiled just fine on Linux? Is MinGW more sensitive? https://github.com/m13253/lvdo/blob/master/src/Makefile To be honest, this compilation procedure appears to be doing something I am not familar with in that it appears to be sharing the code from parsing and utility methods from two separate file to produce to separate targets, something I have never done. – Skylion Jun 13 '15 at 18:27
  • Perhaps you should [edit] your question, to paste in a transcript of make's output, when you run it. – Keith Marshall Jun 14 '15 at 09:21
  • @user3629249, the `.c` dependencies on the `.h` will not simply be ignored; if the `.h` file happens to be newer than either of the `.c`s, then make will want to remake the out-of-date `.c`, (maybe both of them). There is no `%.c: %.h` rule to tell it how to do this, so it _must_ fail. – Keith Marshall Jun 14 '15 at 10:12

4 Answers4

1

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).

Keith Marshall
  • 1,980
  • 15
  • 19
0

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
user3629249
  • 16,402
  • 1
  • 16
  • 17
  • It's complaining about a missing separator on line 24? So I can't even get it to test it to ensure it works. Also: -Wextra -pedantic do not help diagnose the problem. Moreover, this make file WAS working until I reopened the project today – Skylion Jun 13 '15 at 19:05
0

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.

Skylion
  • 2,696
  • 26
  • 50
0

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.

Gatl
  • 1
  • 1