I recently started to take over a QT4.8 project for embedded Linux. After using qmake and .pro file to generate Makefiles in the project, it could not build properly.
The Makefile.Debug snippet causing problem is as following:
{..\GriduiWin}.cpp{debug\}.obj::
$(CXX) -c $(CXXFLAGS) $(INCPATH) -Fodebug\ #<<
$<
<<
For << in the end, make is complaining for the missing tab at the beginning.
For #<< at the end of the second line, I couldn't figure out what is the issue here. The error message is << was unexpected at this time.
What does #<< mean in Makefile? Is this specific from qmake generated files? Or is this a reasonable syntax? How could I deal with this error? Thanks for help.
This generated Makefile turns out to be for nmake instead. Errors no longer shows when compiling with Microsoft Visual Studio command line tools. Thanks to MadScientist for the hint.
Related
Some 10-15 years back I had used an open source utility that hides all gcc output for a file compilation unless there is an error. I can't remember the name of the command / utility. You had to use it in the Makefile via CXX / CPP flags, just like distcc or ccache.
Sample output where the file compiles successfully
Compiling aes-ctr.c ... [ok]
[looks a bit like the gentoo openrc init process that prints ok]
Sample output where the file fails to compile
gcc -I/usr/include -L/usr/lib -l math aes-ctr.c
Include directory '/usr/include' does not exist
Other nested gcc error messages
More gcc error messages...
...
I did quite a bit of Googling and Stackoverflow searching but could not locate the utility. If anyone could help me remember what this utility was, I would really appreciate it. Thanks!
PS: I distinctly remember that it was C code that had to be first compiled (maybe from openssl or gentoo?), and not colorgcc.pl.
The utility is called ccdv
It is now hosted # https://github.com/IngwiePhoenix/ccdv-rmx
From the help file :
$ ccdv
Usage: ccdv /path/to/cc CFLAGS...
I wrote this to reduce the deluge Make output to make finding actual problems easier. It is intended to be invoked from Makefiles, like this.
Instead of:
.c.o:
$(CC) $(CFLAGS) $(DEFS) $(CPPFLAGS) $< -c
Rewrite your rule so it looks like:
.c.o:
#ccdv $(CC) $(CFLAGS) $(DEFS) $(CPPFLAGS) $< -c
It was earlier hosted # https://sourceforge.net/projects/ccdv/
I'm trying to get a custom compiler working in CLion and having a bear of a time. Can anyone help me find out what I'm doing wrong? I have the full code on Github.
What I have
The command line tools are all behind the same executable named mpw. So the C compiler is behind mpw SC, the linker is behind mpw link. There's also a tool named Rez to add some metadata to the executable, but I'm fine if CLion just ignores that.
I'm using a make file to do the actual build.
I've created a custom compiler definition YAML and selected it in CLion's project settings. I tried to follow the Jetbrains docs [1] [2] but couldn't find out what code insight target name to use (It eventually compiles for 68000 CPU, old MacOS, anyone know where I can find a list of allowed clangd target names?).
The Makefile works when I call make clean or make all from command line.
Problem
When I open the folder in CLion, it tries to parse the Makefile and reports:
(x) Analysing makefile
(x) No compilation commands found
Goal
Get CLion to see all my code (including system headers at ~/mpw/Interfaces/CIncludes) so I can use its code navigation to auto-complete code. Refactoring would be nice too.
Get CLion to understand my Makefile so I can build using the "hammer" icon inside CLion.
Custom Compiler Definition
compilers:
- description: "MPW SC"
match-sources: ".*\\.c"
match-language: "C"
match-compiler-exe: "(.*/)?mpw SC"
code-insight-target-name: mpw
include-dirs:
- ${user-home}/mpw/Interfaces/CIncludes
defines-text: "
#define __MRC__ 0x0700
#define OLDROUTINENAMES 1
"
Makefile
SOURCES=SillyBalls.c
RFILES=SillyBalls.r Size.r
EXECUTABLE=SillyBalls
MPW=~/Programming/mpw/build/bin/mpw
RINCLUDES=~/mpw/Interfaces/RIncludes
LDFLAGS =-w -c 'SILB' -t APPL \
-sn STDIO=Main -sn INTENV=Main -sn %A5Init=Main
LIBRARIES={Libraries}Stubs.o \
{Libraries}MacRuntime.o \
{Libraries}IntEnv.o \
{Libraries}Interface.o \
{Libraries}ToolLibs.o \
{CLibraries}StdCLib.o
TOOLBOXFLAGS=-d OLDROUTINENAMES=1 -typecheck relaxed
OBJECTS=$(SOURCES:%.c=obj/%.o)
all: prepass bin/$(EXECUTABLE)
prepass:
mkdir -p obj bin
bin/$(EXECUTABLE): $(OBJECTS)
$(MPW) link $(LDFLAGS) $(OBJECTS) $(LIBRARIES) -o $#
Rez -rd $(RFILES) -o $# -i $(RINCLUDES) -append
obj/%.o : %.c
$(MPW) SC $(TOOLBOXFLAGS) $< -o $#
clean:
rm -rf bin obj
Thanks to #JohnBollinger for getting me on the right track:
CLion is apparently not smart enough to recognize $(MPW) SC as mpw SC. If I change it to
CC="~/Programming/mpw/build/bin/mpw SC"
CLion is happy, but of course there is no file named mpw SC.
So my solution was to create a shell script sc.sh:
#!/bin/zsh
~/Programming/mpw/build/bin/mpw SC $#
and then set
CC=./sc.sh
and
match-compiler-exe: "(.*/)?sc.sh"
and then use ./sc.sh everywhere where I used to have $(MPW) SC
CLion recognizes it, starts indexing the system headers, and the "hammer" icon triggers a build all just as desired.
first, thanks to all.
I ' ve been kind of 3 hours trying to find out whats wrong, I have done a deep research on the internet and I found nothing that worked for me.
I' ve tried a lot of examples which ended the same way; missing separator or nothing to be done.
What could it be?
My .c and .h are called the same way 3enRayaPunteros.c/h
Here's my makefile's code:
Juego: 3enRayaPunteros.o
gcc -o Juego 3enRayaPunteros.o
3enRayaPunteros.o: 3enRayaPunteros.c 3enRayaPunteros.h
gcc -c 3enRayaPunteros.c
Thank you so much:
Try
Juego: 3enRayaPunteros.o
gcc -o $# $+
3enRayaPunteros.o: 3enRayaPunteros.c 3enRayaPunteros.h
gcc -c -o $# $^
You want your executable Juego to depend on a .o file. That object file needs to depends on your source files .c, .h, ....
It's common practice to refer to the target name with $#, refer to all the prerequisites with $+ and refer to the first prerequisite with $^.
Missing seperator usually means you are mixing up spaces and tabs. Make is very fiddly when it comes to this so do NOT use tabs to indent anything but recipes. Nothing to be done means exactly what the message says: there is nothing to be done for what you asked make to do.
I have written complicated C and C++ makefiles in the past. However, I cannot seem to get my D makefile to work. It throws over a thousand lines of "undefined reference" errors, which look as if Phobos is failing to be linked. How can I fix that?
I am using GNU make and LDC2 on Fedora 19 Linux.
Edit: Compiling and linking directly using LDC2 works correctly. Only when invoked with 'make' is there an error. It seems that make is trying to invoke a separate linker.
Edit 2: Here is my makefile:
# This macro contains the source files
sources := $(wildcard *.d)
binaries := $(sources:%.d=%)
all: $(binaries)
%.o:%.d
ldc2 $< -O5 -check-printf-calls
Deleting the .o fixed it.
I don't know the intricacies of Pattern Rules, but I believe that is where your problem lies.
%.o:%.d
ldc2 $< -O5 -check-printf-calls
You've asked make to convert every .d file into a .o by calling the ldc2 command. However, you aren't requesting ldc2 to build object files, you're asking it to build an executable (I don't know which flag you want dmd/gdc: -c). Though I would have expected compiler errors from this before linker.
By removing the .o I must assume that Make is instead passing all the .d files at once rather than individually.
I have a legacy code written using fortran 77. I'm trying to build it with gfortran. But I seem to be failing at the stage where I include the libraries in the build. The dozens of *.f source files compile fine, but when they are being linked, I get a bunch of "undefined reference" errors all relating to subroutines and functions that are defined in my libraries. I already ran the makefile for the libraries first, so the variables I need should all be exported. I'm playing with the "-L" option, but can't get it to work as desired.
First, here's my syntax of the linking line in my makefile:
29 $(PROGRAM): $(SRCS) $(LIBS)
30 $(FC) $(FLFLAGS) -o $# $+ -L$(DIRLIB)
PROGRAM is the program name, SRCS are all the compiled source files, LIBS is set to two different files - an archive file (file.a) and a file.o file.
FC is gfortran, I don't have any specific linking flags for FLFLAGS as of now, and DIRLIB is the main directory of the libraries.
The thing is that my *.o files that resulted from building my librarires don't reside in just the main directory, DIRLIB. DIRLIB contains several directories, all with their own *.o files that are needed by my code.
I tried adding each individual directory after the -L option (e.g. DIRLIB/DIR1/*.o DIRLIB/DIR2/*.o DIRLIB/DIR3/*.o), but I eventually start getting errors that some subroutines are multiply defined.
All this business of user-defined libraries and archive files just confuses me and I'm pretty new to making makefiles in the first place, so I'm just taking a shot in the dark here that somebody might be able to help me shed some light on this.
Libraries need to come after the .o files that reference them in the linking command.
I'm guessing the object file in LIBS comes after the library, but needs some of the procedures from it. Can you show the command that is actually run (with all variables expanded), to confirm this?
I tried to build this code again using the library. It worked this time. I'm pretty sure I'm doing the same thing in my makefile as I did before, so it must be related to the library I had. Maybe somebody altered it along the way and inadvertently broke it. But I got a fresh clean copy of the library. My steps are to:
1) run the makefile for the library source files; it creates a library.a archive file
2) run my code makefile:
it has a line to specify the location of this archive file and assign it to "DIRLIB"
DIRLIB := ../library
then the linking command of the makefile becomes
$(FC) $(FLFLAGS) -o $# $+ -L$(DIRLIB) -lskit
FC is my compiler, FLFLAGS are my linking flags, -L is the option specifying the location of libraries to be included and -lskit is a crucial option which appears to allow the use of F77 libraries... without the -lskit option, I get many undefined reference errors. It may have been that last time I was not including this -lskit option at the end.