What is Eclipse CDT is doing with 'make' under the hood - c

I'm on Windows 7 and have MinGW/gcc installed. I'm using the Eclipse CDT plugin to compile and build my first simple C programs, and am trying to follow what exactly the plugin is doing under the hood.
I create a new "Hello World!" C project with the following directory structure:
helloworld/
src/
helloworld.c
Where helloworld.c is:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
puts("Hello World!");
return EXIT_SUCCESS;
}
So I created a Run Configuration in Debug Mode (as opposed to "Release Mode", not a "Debug Configuration" in typical Eclipse parlance!) and ran my app, and it works beautifully, printing "Hello World!" to the Eclipse console.
Now I'm looking on my file system and the file/project structure is like so:
helloworld/
src/
helloworld.c
Debug/
src/
helloworld.d
helloworld.o
subdir.mk
helloworld.exe
makefile
objects.mk
source.mk
I assume that running my Run Configuration in Eclipse (hence compiling/building/running helloworld inside Eclipse) created everything under Debug. Furthermore I assume that helloworld.d and helloworld.o are compiled binaries, and that helloworld.exe is the packaged executable containing those binaries and everything they'red linked to (stdio and stdlib). I also assume makefile is the actual Make file (buildscript), and that the *.mk files are somehow inputs to that buildscript. So, for starters, if any of those assumptions are wrong, please begin by correcting me!
When I open makefile I see this:
################################################################################
# Automatically-generated file. Do not edit!
################################################################################
-include ../makefile.init
RM := rm -rf
# All of the sources participating in the build are defined here
-include sources.mk
-include src/subdir.mk
-include subdir.mk
-include objects.mk
ifneq ($(MAKECMDGOALS),clean)
ifneq ($(strip $(C_DEPS)),)
-include $(C_DEPS)
endif
endif
-include ../makefile.defs
# Add inputs and outputs from these tool invocations to the build variables
# All Target
all: helloworld
# Tool invocations
helloworld: $(OBJS) $(USER_OBJS)
#echo 'Building target: $#'
#echo 'Invoking: Cross GCC Linker'
gcc -o "helloworld" $(OBJS) $(USER_OBJS) $(LIBS)
#echo 'Finished building target: $#'
#echo ' '
# Other Targets
clean:
-$(RM) $(EXECUTABLES)$(OBJS)$(C_DEPS) helloworld
-#echo ' '
.PHONY: all clean dependents
.SECONDARY:
-include ../makefile.targets
Please note: I am not looking for someone to explain to me how Make works, I can RTFM for that ;-)
I am just trying to understand what it would take to compile, build and run helloworld from the command-line, outside of Eclipse. What command line invocations would I need to accomplish this, and why? Once I see that, combined with perusing Make docs, I should be able to fill in the gaps and understand everything that is going on.

That depends a bit on the paths that Eclipse generates in the files source.mk and objects.mk but most likely you need to cd into the Debug folder.
Inside of that, you can then run make all to compile the project.
If Eclipse generated absolute paths, you can use make -f .../path/to/helloworld/Debug/makefile all from anywhere.

The *.o files are the object file(s) created by compilation. these files are typically build by a command like:
Gcc -ansi -Wall -pedantic -c helloworld.c -o helloworld.o
(apologies foe capitalization of gcc, my iPad insists on correct my typing)
The *.exe is the actual executable, which may or may not contain the library functions. This depends on static versus dynamic linking. The executable is created typically by:
Gcc helloworld.o -o helloworld.exe
The *.d files are dependency files, built by gcc attempting to determine dependencies between files, typically built with the following command
MAKEDEPEND = gcc -M $(CPPFLAGS) -o $*.d $<
(Rule taken from make online documentation).
So,to answer your final question, to compile from the command line, a command like:
Foo gcc -ansi -WAll -pedantic helloworld.c -o helloworld.exe
Should do the trick for you. Note, the flags to the compiler are the minimum that I like to use, you will probably have a different set of switches.
Hopes this help,
T

Related

Problems with inclusion of C header file with automatically generated makefile

I have started to develop the C language software in the Xilinx Vitis IDE which Eclipse based. Organization of my project is following:
-Application
-Drivers
-drivers
-Adc
-Pwm
-Pwm.c
-Pwm.h
-Utils
-Bits.h
-Maths.h
All the directories i.e. Application, Drivers and Utils are linked into the workspace via "Link folder" option. The only one way how I was able to include the Bits.h into the Pwm.c was to specify the whole path to the Bits.h on my disk. Otherwise the compiler reports fatal error: Bits.h: No such file or directory.
The compilation process is managed by the automatically generated makefile with this content:
# Makefile generated by Xilinx.
PROCESSOR = ps7_cortexa9_0
LIBRARIES = ${PROCESSOR}/lib/libxil.a
BSP_MAKEFILES := $(wildcard $(PROCESSOR)/libsrc/*/src/Makefile)
SUBDIRS := $(patsubst %/Makefile, %, $(BSP_MAKEFILES))
ifneq (,$(findstring win,$(RDI_PLATFORM)))
SHELL = CMD
endif
all: libs
#echo 'Finished building libraries'
include: $(addsuffix /make.include,$(SUBDIRS))
libs: $(addsuffix /make.libs,$(SUBDIRS))
clean: $(addsuffix /make.clean,$(SUBDIRS))
$(PROCESSOR)/lib/libxil.a: $(PROCESSOR)/lib/libxil_init.a
cp -f $< $#
%/make.include: $(if $(wildcard $(PROCESSOR)/lib/libxil_init.a),$(PROCESSOR)/lib/libxil.a,)
#echo "Running Make include in $(subst /make.include,,$#)"
$(MAKE) -C $(subst /make.include,,$#) -s include "SHELL=$(SHELL)" "COMPILER=arm-none-eabi-gcc" "ASSEMBLER=arm-none-eabi-as" "ARCHIVER=arm-none-eabi-ar" "COMPILER_FLAGS= -O2 -c" "EXTRA_COMPILER_FLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -nostartfiles -g -Wall -Wextra -g3 -O0"
%/make.libs: include
#echo "Running Make libs in $(subst /make.libs,,$#)"
$(MAKE) -C $(subst /make.libs,,$#) -s libs "SHELL=$(SHELL)" "COMPILER=arm-none-eabi-gcc" "ASSEMBLER=arm-none-eabi-as" "ARCHIVER=arm-none-eabi-ar" "COMPILER_FLAGS= -O2 -c" "EXTRA_COMPILER_FLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -nostartfiles -g -Wall -Wextra -g3 -O0"
%/make.clean:
$(MAKE) -C $(subst /make.clean,,$#) -s clean
clean:
rm -f ${PROCESSOR}/lib/libxil.a
It is obvious that my "solution" is unacceptable. So I would like to ask you for an advice how to resolve this issue correctly. Thanks in advance for any suggestions.
You can add include paths to the project. These are paths where the compiler will search for include files. Any include file located in one of the directories in the include paths list should be found; you do not need to specify its path when including the file.
How you do this in the Xilinx environment appears to depend on how your project is set up.
If it is a managed make project:
Properties -> C/C++ Build
In "Tools Settings" tab select the "Include Paths"
If it is a standard make project:
Properties->C/C++ Include Paths and Symbols>
Then "Add External Include Path"
If it gives you the option to add the path as absolute or relative path, choose relative path; this allows another user to put the project, with the same internal directory structure, in a different place on the hard drive, which is what you want. In the screenshots in the documentation I referenced, the paths appear relative.
See this documentation for more details, screenshots, etc.
Note: I am answering based on the documentation; I have not worked with this IDE myself.
Note also that you can use relative paths in an #include directive, but they are not necessarily relative to the location of the file that includes them. They are more likely to be relevant to the root of the project (basically, wherever 'make' will be effectively run).

How to change the following Makefile of LINUX ,so that it works on MACOS as well [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I have a Makefile on my Linux Pc.I want to build and run the same program on MacOS too . How to edit the following Makefile ?
I want to compile a C program that has a header file of a graphics library EGGXProCALL JAXA "eggx.h".
I already installed Xcode ,XQuartz.
I have installed EGGX file on the following directory .
[Home#/opt/eggx]$
I have a C file in the following directory.
[Home#~/Desktop/development]$
I have checked the followings .
① gcc works fine here [Home#~/Desktop/development]$
② even the sample program to display a digital clock works ,
when the current directory is [Home#/opt/eggx]$
③ PROBLEM
when I tried to build [make] the program from [Home#~/Desktop/development]$ by using the makefile that I had in Linux.
I always get the following error message.
[Home~/Desktop/development]$ sudo make
gcc -c main.c
main.c:7:10: fatal error: 'eggx.h' file not found
#include <eggx.h>
^~~~~~~~
1 error generated.
make: *** [main.o] Error 1
[Home#~/Desktop/development]$
Here is the Makefile
# Makefile
OBJS = main
$(OBJS): $(OBJS).o
# gcc -O2 -Wall $(OBJS).c -o $(OBJS) -I/usr/local/include -L/usr/local/lib64 -leggx -lX11 -lm
gcc $(OBJS).c -o $(OBJS) -I/usr/local/include -L/usr/local/lib64 -leggx -lX11 -lm
$(OBJS).o: $(OBJS).c
gcc -c $(OBJS).c
.PHONY: clean
clean:
rm -f $(OBJS) $(OBJS).o
You must do things in the correct order and not proceed to the next step until you have correctly completed the previous step.
1. Download, and extract the library.
The download is normally done with git clone or scp to copy the source files from somewhere.
The extract (unpack from archive) is normally done with:
tar -xvf eggx-0.93r5.tar
That will normally create a new directory (with the same name as the tar-file but without the .tar extension) like:
eggx-0.93r5
2. Build the library.
Normally you need to change directory into the newly created one and run make. I gave you the Makefile last time so you need to do:
cd eggx-0.93r5
cp MAKEFILEFROMMARK Makefile
make
There should be no errors. If there are errors, you must solve them and then run:
make clean # delete any rubbish from previous failed build
make
3. Install the library.
You normally do this with:
make install
What that actually does depends on the package you are installing, but as a general rule, it will copy the header files and the libraries you just made into a "known" location, like /usr/local or /opt/package. The idea is to make all the files your own code will need available to all users of the computer by "publishing" or installing them to known locations.
4. Work out how to compile a simple C program that uses the library.
You should do the following steps in a completely different directory from where you downloaded the library to - do not mix your code with the library's code.
If your program uses eggx.h like this:
#include "eggx.h"
then you need to find where eggx.h is like this:
find /usr /opt /Users -name eggx.h
If that results in:
/path/to/somewhere/include/eggx.h
that means you must add this to your gcc command to tell the compiler how to find it:
gcc -I/path/to/somewhere/include ...
If your library is called libeggx.a, you need to find that too:
find /usr /opt /Users -name "libegg*a"
If that results in:
/path/to/somewhere/lib/libeggx.a
that means you need to add this to your gcc command to tell the linker where it is and what it is called:
gcc ... -L/path/to/somewhere/lib -leggx
If your program uses X11, you must install XQuartz on a Mac, and add the flags/switches for X11 into your compilation:
gcc ... -I /opt/X11/include -L /opt/X11/lib -lx11 ...
So, putting all that together, if your program is called program.c, you will compile and link with:
gcc program.c -o program -I/path/to/somewhere/include -I /opt/X11/include -L /opt/X11/lib -lx11 -L/path/to/somewhere/lib -leggx
and then run with:
./program
5. Make a Makefile that enshrines what you learned at (4).
That might look something like this:
EGGINC = -I /path/to/somewhere/include
EGGLIB = -L /path/to/somewhere/lib -leggx
X11INC = -I /opt/X11/include
X11LIB = -L /opt/X11/lib -lx11
$(OBJS): $(OBJS).o
gcc $(OBJS).c -o $(OBJS) $(EGGLIB) $(X11LIB)
$(OBJS).o: $(OBJS).c
gcc -I/usr/local/include $(EGGINC) $(X11INC) -c $(OBJS).c
You build your program in two steps:
Build the source file into an object file
Link the object file with libraries to create the final executable program
The preprocessor (which handles #include directives) is part of the building of the object file. So all flags that are needed for creation of the object files (like the -I option) should be present there and only there.
So the two rules could be changed as follows:
$(OBJS): $(OBJS).o
gcc $(OBJS).c -o $(OBJS) -L/usr/local/lib64 -leggx -lX11 -lm
$(OBJS).o: $(OBJS).c
gcc -I/usr/local/include -c $(OBJS).c
Of course that assumes that the EGGX library was installed in /usr/local.

How can I efficiently patch an external library and compile it in a Makefile for a C project?

I'm working on a C project which needs an external open source library.
In particular, it needs a version I patched myself in order to add some needed features.
At the moment I'm using a Makefile which expects a statically compiled version of the patched library inside the ./lib folder (let's call it libpatched.a), and the corresponding header files in ./include/libpatched.
The following are the main parts of the aforementioned Makefile:
EXECNAME=MyExecutable
CC=gcc
SRC_DIR=src
OBJ_DIR=obj
SRC=$(wildcard $(SRC_DIR)/*.c)
OBJ=$(SRC:$(SRC_DIR)/%.c=$(OBJ_DIR)/%.o)
CFLAGS += -Wall -O2 -Iinclude -Iinclude/libpatched
LDFLAGS += -Llib
LDLIBS += -lpatched
.PHONY: all clean
all: $(EXECNAME)
$(EXECNAME): $(OBJ_CC)
$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $#
$(OBJ_DIR)/%.o: $(SRC_DIR)/%.c
$(CC) $(CFLAGS) -c $< -o $#
clean:
$(RM) $(OBJ_DIR)/*.o
This Makefile is working correctly; however, I was looking for a more flexible solution, which does not need any statically compiled library before make is called.
What I would like to accomplish is having a Makefile which does something like:
Download a specific version of the original library (in order to never have any compatibility problem)
Apply a patch using patch and a diff file (.patch)
Compile the patched library (either statically or dynamically) for the current platform, using cmake, as required by the original library
Compile my project, using libpatched
Are these steps valid in your opinion, or is there a much better way to handle this need for a patched library?
If yes, as I'm not an expert at all in creating Makefiles, is there an easy way to reach this goal by simply leveraging on a properly written Makefile?
Which could be the best way to do so?
Thank you very much in advance.
I've done exactly this before, when building cross compiler etc with my patches for my operating system kernel. You can use the wget or curl commands in the Makefile. For example something like
# foo.tar.gz needs to be downloaded
foo.tar.gz:
wget https://download.source.from/here/foo.tar.gz -O foo.tar.gz
# the makefile requires the downloaded file.
foo_src/CMakeLists.txt: foo.tar.gz
mkdir -p foo_src
cd foo_src && tar xfz ../foo.tar.gz
# patch the library if flag not present
foo_patched.flag:
cd foo_src && patch -p1 ../foo.patch
touch foo_patched.flag
# this depends on patching
libpatched.a: foo_src/CMakeLists.txt foo_patched.flag
cd foo_src && cmake
cp foo_src/libfoo.a libpatched.a
The Makefile format is very simple - unlike CMake! - the rules just say: "to generate the file on the left, please build the prerequisites on the right side first. Then execute these commands to actually generate the file on the left hand side"

Using make for cross platform compilation

I am currently developing a C project under Linux and Win32. The 'deliverable' is a shared library, and all the development is done under Linux with the GNU tool chain. I am using a Makefile to compile the shared library.
Every now and then I have to build a .dll under Win32 from the same src.
I've installed MinGW on the Win32 box such that I can use make and get far fewer complaints from the compiler (in comparison to MSVC). I'm at a stage where the src code compiles on both platforms
But the Linux Makefile and Win32 Makefile are different. I'm curious as how to best handle this - should I:
have 2 makefiles, e.g. Makefile for linux and Makefile.WIN32 and then run make -f Makefile.WIN32 on the Windows box
Should I make a different target in a single Makefile and do something like make WIN32 on the Windows box
Should I ditch make and use CMake (is the juice worth the squeeze for such a simple project, i.e. 1 shared library)
Use a single make file and put the platform-specifics in conditionals, eg
ifeq ($(OS),Windows_NT)
DLLEXT := .dll
else
DLLEXT := .so
endif
DLL := libfoo$(DLLEXT)
lib : $(DLL)
I use UNAME := $(shell uname) within my Makefile to detect the platform (Linux or MS-Windows).
I provide below a complete example based on make and gcc to build a shared library: *.so or *.dll depending on the platform.
The example is basic/simple/stupid to be more understandable :-)
To use make and gcc on MS-Windows, Cygwin or MinGW can be installed.
The example uses five files:
├── app
│ └── Makefile
│ └── main.c
└── lib
└── Makefile
└── hello.h
└── hello.c
The Makefiles
app/Makefile
app.exe: main.o
gcc -o $# $^ -L../lib -lhello
# '-o $#' => output file => $# = the target file (app.exe)
# ' $^' => no options => Link all depended files
# => $^ = main.o and other if any
# '-L../lib' => look for libraries in directory ../lib
# '-lhello => use shared library hello (libhello.so or hello.dll)
%.o: %.c
gcc -o $# -c $< -I ../lib
# '-o $#' => output file => $# = the target file (main.o)
# '-c $<' => COMPILE the first depended file (main.cpp)
# '-I ../lib' => look for headers (*.h) in directory ../lib
clean:
rm -f *.o *.so *.dll *.exe
lib/Makefile
UNAME := $(shell uname)
ifeq ($(UNAME), Linux)
TARGET = libhello.so
else
TARGET = hello.dll
endif
$(TARGET): hello.o
gcc -o $# $^ -shared
# '-o $#' => output file => $# = libhello.so or hello.dll
# ' $^' => no options => Link all depended files => $^ = hello.o
# '-shared' => generate shared library
%.o: %.c
gcc -o $# -c $< -fPIC
# '-o $#' => output file => $# = the target file (main.o)
# '-c $<' => compile the first depended file (main.cpp)
# '-fPIC' => Position-Independent Code (required for shared lib)
clean:
rm -f *.o *.so *.dll *.exe
The source code
app/main.c
#include "hello.h" //hello()
#include <stdio.h> //puts()
int main()
{
const char* str = hello();
puts(str);
}
lib/hello.h
#ifndef __HELLO_H__
#define __HELLO_H__
const char* hello();
#endif
lib/hello.c
#include "hello.h"
const char* hello()
{
return "hello";
}
The build
Fix the copy-paste of Makefiles (replace leading spaces by tabulation).
> sed -i 's/^ */\t/' */Makefile
The make command is the same on both platforms. The given output is for MS-Windows (unnecessary lines removed).
> cd lib
> make clean
> make
gcc -o hello.o -c hello.c -fPIC
gcc -o hello.dll hello.o -shared
> cd ../app
> make clean
> make
gcc -o main.o -c main.c -I ../lib
gcc -o app.exe main.o -L../lib -lhello
The run
The application requires to know where is the shared library.
On MS-Windows, the simple/basic/stupid way is to copy the library where the application is:
> cp -v lib/hello.dll app
`lib/hello.dll' -> `app/hello.dll'
On Linux, use the LD_LIBRARY_PATH environment variable:
> export LD_LIBRARY_PATH=lib
The run command line and output are the same on both platforms:
> app/app.exe
hello
As somebody who has used both autotools and CMake, I would recommend using CMake over rolling your own Makefiles and using autotools. CMake has so many useful, easy to use benefits, even if it is a simple project. For example, CMake will create an NSIS installer, manage production vs. debug compilation and has a nice testing framework. The one knock I had was that it was kind of hard to find real examples of how to use it. So much open source software uses autotools that realworld examples for it are easy to find. However, if you download the CMake source, there are lots of examples in the Example directory and Test directory.
In other words, the Juice is worth the squeeze.
I had a similar issue a few years back, and found that cmake is much easier for cross-platform compilation AND will use whatever compiler is native for that system. Syntax is clearer and abstracts details that are unnecessary for the most part (sometimes that got in the way, but usually there was a way around it)
As a primary advice, I suggest using libtool, autoconf and automake; they make cross-compilation very easy, and much easier than CMake.
If you are going the hand-crafted route, I would suggest going with different targets. Switching between makefiles tends to hide otherwise obvious errors in Makefiles, e.g. duplicately used objects with different rules. Example: The object foo.o is compiled for the DLL target and for the .so target, but with different flags. If someone switches Makefiles, the existing .o file with wrong flags is used, breaking the build. If you are using one Makefile, this will become obvious through rule conflicts.
If you are willing to use MSYS2 on Windows you might get it to run without
making any changes at all compared to your code written for Linux.
This goes for your C/C++ source code as well as for your makefile.(!)
I have been developing code for Linux exclusively. When I tried running it
inside an MSYS2 terminal, the code turned out to work just fine, and
produced a Windows binary executable. I was positively surprised.
You will need to know how to install and use MSYS2, of course. For example,
to install make and g++, in an MSYS2 terminal run the commands:
yes | pacman -Syu msys/make
yes | pacman -Syu gcc
If you want to find out where in Windows g++ has been installed, you can run
where g++ in the MSYS2 terminal.
References:
https://www.msys2.org/wiki/MSYS2-installation/
https://github.com/msys2/MSYS2-packages/issues/293

What is wrong with this Makefile? (header files not found)

I am modifying an old makefile in order to build a C extension for postgreSQL. The Makefile currently looks like this:
PGLIB = /usr/lib/postgresql/8.4/lib
PQINC = /usr/include/postgresql/8.4/server
CC=gcc
override CFLAGS+= $(CFLAGS_SL) -DPG_AGGREGATE
SHLIB = pg_myextlib
SRC = foo.c \
foobar.c
OBJS = foo.o \
foobar.o
all: $(OBJS)
$(CC) -shared -o $(SHLIB)$(DLSUFFIX) $(OBJS) -I$(PQINC)
cp *.so $(PGLIB)
clean:
rm -f $(SHLIB) $(OBJS)
The error I get when I run make is:
common.h:58:22: error: postgres.h: No such file or directory
Which suggests that the include path is not being added (the file exists in $PQINC).
Its a long time since I wrote the Makefile - and I haven't written many since. As an aside, I am pretty sure that 'shared' is not the gcc flag to build shared libs on Ubuntu (my current dev box) - I think the flag should be 'fPIC' - can someone confirm this?
I am runing gcc v4.4.3 on Ubuntu 10.0.4 and compiling for use with PG 8.4
Try moving the -I$(PQINC) from target all to the end of line that starts with override CFLAGS.
Placing -Isomething on the compiler line which turns object files, like those in $(OBJS), into executable will have no effect whatsoever.
You need to do it when you compile the source files.
Since your makefile doesn't explicitly show the rule for processing source files, it may well be using a default one, which is incredibly unlikely to know about PQINC.
You seem to be using the default rules to build foo.o from foo.c, which doesn't have your -I. Try adding the following rule to your Makefile:
.c.o:
$(CC) $(CFLAGS) -c $< -o $# -I$(PQINC)

Resources