I have been using GCC for many years to compile ARM projects developed using Eclipse. I have decided it is time to update the tools I'm using.
I have been using a version of GCC 'cribbed' from CodeSourcery, but I have upgraded to the latest version from http://gnutoolchains.com/arm-eabi/. All works well, except for Make:
The CodeSourcery folder includes a version named cs-make.exe, dated 30/04/2013. I have downloaded a newer version of GCC/GDB from http://gnutoolchains.com/arm-eabi/ into a folder that I named SysGCC. It contains the app make.exe, dated 27/05/2015.
I have modified my makefile to use SysGCC and it compiles correctly. However, if I then modify my project to run make.exe instead of cs-make.exe the console shows the following errors:
make -j -k all
make: *** No rule to make target `IO.o', needed by `Display.elf'.
make: *** No rule to make target `XTPcommon.o', needed by `Display.elf'.
make: *** No rule to make target `DisplayCommon.o', needed by `Display.elf'.
.
.
The contents of my makefile are quite complex, and include the following:
%.o : %.c makefile
$(COMPILE) -c $(CFLAGS) $< -o $(OUTPUT_FOLDER)/$#
$(COMPILE) -MM $(CFLAGS) $< > $(OUTPUT_FOLDER)/$(addsuffix .d, $(notdir $(basename $#)))
Since they build correctly with cs-make.exe I can see no reason why they shouldn't build with make.exe. So, what's going wrong?
Thank you both for your responses.
I spent many frustrating hours trying different combinations of GCC, OpenOCD, JTag drivers and Eclipse plug-ins. I have numerous build versions of a project that all work with my previous toolchain and I tried copying various of these into the project I use to test the new toolchain.
I eventually found the solution. I had somehow managed to corrupt my project to use source files from one build version and a makefile from another version, and there were incompatibility issues between them.
The symptoms were very deceptive and led me up various blind alleys. I still can't understand why it worked with one version of make but not with the other.
When I corrected the project everything worked correctly.
Related
I need to obtain the information on the C-compiler used to build an installed program. I am guessing a rt or a lib can report that, but nothing concrete. Not that the program would be installed in /usr/... or a similar place, and hence would not have access to the build directory to get the relevant info.
Well behaved programs should understand the --version argument.
Packaged programs (i.e. those installed with dpkg -i or apt-get install of a .deb package on Debian, etc...) also know their package version and source.
You might try to use strings on the binary executable. However, such meta-data (about the version of the C compiler used to build the program) might have been stripped (e.g. by the strip command).
If you are developing the program (i.e. its C source code) and can change it, you might consider adding something like
timestamp.c: Makefile
echo 'const char timestamp[]=' > $#
date +'"built with $(shell $(CC) --version) on %c";' >> $#
yourprogram: $(OBJECTS) timestamp.o
$(LINK.c) $(LDFLAGS) $< -o $# $(LDLIBES)
$(RM) timestamp.c
in your Makefile (details could be wrong, but you get the idea)
I was searching for a way to create mocking objects with c-code until I stumbled upon cmockery.
For me it seems to be the best mocking software available since it doesn't have a lot of dependencies.
I'm working in ubuntu and downloaded the tarball cmockery from https://code.google.com/p/cmockery/downloads/list
I ran the ./configure, make and make install.
I am able to execute the given examples but I just can't figure out how to get it working on my own projects. I had a look at the configure and makefile to try and find out how they did it, but that was no success. I think it's the linking that's causing my problems.
Files of cmockery can be find at:
/usr/local/include/google/cmockery.h
/usr/local/lib/libcmockery.la
/usr/local/lib/libcmockery.a
/usr/local/lib/libcmockery.so.0.0.0
/usr/local/lib/libcmockery.so.0
/usr/local/lib/libcmockery.so
I tried copying the example files calculator.c and calculater_test.c to a separate directory and compile them there.
This is what I did:
gcc -c -o calculator.o calculator.c
gcc -c -o calculator_test.o calculator_test.c -I /usr/local/include/google/
gcc -o run *.o -L /usr/local/lib/
At the last step I got a lot of undefined references to all functions specific to cmockery and the error:
collect2: error: ld returned 1 exit status
I guess I'm messing things up with the linker but I can't find anywhere how it should be done correctly.
You are missing -lcmockery:
gcc -o run *.o -L /usr/local/lib/ -lcmockery
I have been trying to figure out how to create a C program that can be compiled for all of the major operating systems. I have considered using makefiles so I would just have to change the target OS, but I have a few problems. My first problem is that I cannot figure out how to change the target OS so I can compile on one OS but use the application on all OS's. My second issue is that I cannot figure out how to make it automatically compile all .c files in the src directory, so I do not have to modify the makefile every time I add a new file. Does anybody know how to do this stuff?
My current makefile (currently unmodified from here)
CC=gcc
CFLAGS=-c -Wall
LDFLAGS=
SOURCES=main.cpp hello.cpp factorial.cpp
OBJECTS=$(SOURCES:.cpp=.o)
EXECUTABLE=hello
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
$(CC) $(LDFLAGS) $(OBJECTS) -o $#
.cpp.o:
$(CC) $(CFLAGS) $< -o $#q2
The GNU Autoconf is a good place to start. I can't give you a complete answer because I don't know what you'd do for Windows except maintain a set of nmake scripts. While there's a learning curve they make it possible to write make files and c-code that work across platforms. It will not only handle multiple source files for you but help you define target such as 'all', 'install,' 'clean,' etc. If you're familiar with downloading a project and then typing './configure' and then 'make install' then you've probably been a user of an Autoconf generated project.
There are other reasons to use Autoconf than just handling multiple source files.
What makes C/C++ development across flavors of Unix difficult is the definition of 'Unix' and C. Different flavors of Unix have slightly different library or system calls depending on what flavor of standards they support. The same is true of C. So, when writing code you'll see #defines specifying a group of preprocessor symbols that define a version of Unix and C that you'd like to use. Going from GCC to HP C or some other vendor's C compiler may include different 'default' levels of behavior, so you need to make the expected behavior explicit.
Second, you need to define what libraries are required. In your build you might need to probe for mysql libraries and decide what to do if those libraries are not installed. In some cases you might need to not build at all or in some cases you might just substitute for another library (like libdb). Having tried writing complex makefiles to support even two operating systems (Solaris and Linux), I would not want to re-invent this wheel.
I'm new to this. Just wanted to ask how to compile a makefile. I am using MinGW compiler in C language. Do I have to save all my files in MinGW\bin? because right now my files are in a different directory.
Appreciate the help.
Excerpt from http://www.mingw.org/wiki/FAQ:
What's the difference between make and mingw32-make?
The "native" (i.e.: MSVCRT dependent) port of make is lacking in some functionality and has modified functionality due to the lack of POSIX on Win32. There also exists a version of make in the MSYS distribution that is dependent on the MSYS runtime. This port operates more as make was intended to operate and gives less headaches during execution. Based on this, the MinGW developers/maintainers/packagers decided it would be best to rename the native version so that both the "native" version and the MSYS version could be present at the same time without file name collision.
So,look into C:\MinGW\bin directory and first make sure what make executable, have you installed.(make.exe or mingw32-make.exe)
Before using MinGW, you should add C:\MinGW\bin; to the PATH environment variable using the instructions mentioned at http://www.mingw.org/wiki/Getting_Started/
Then cd to your directory, where you have the makefile and Try using mingw32-make.exe makefile.in or simply make.exe makefile.in(depending on executables in C:\MinGW\bin).
If you want a GUI based solution, install DevCPP IDE and then re-make.
You have to actively choose to install MSYS to get the make.exe. So you should always have at least (the native) mingw32-make.exe if MinGW was installed properly. And if you installed MSYS you will have make.exe (in the MSYS subfolder probably).
Note that many projects require first creating a makefile (e.g. using a configure script or automake .am file) and it is this step that requires MSYS or cygwin. Makes you wonder why they bothered to distribute the native make at all.
Once you have the makefile, it is unclear if the native executable requires a different path separator than the MSYS make (forward slashes vs backward slashes). Any autogenerated makefile is likely to have unix-style paths, assuming the native make can handle those, the compiled output should be the same.
I have MinGW and also mingw32-make.exe in my bin in the C:\MinGW\bin . same other I add bin path to my windows path. After that I change it's name to make.exe . Now I can Just write command "make" in my Makefile direction and execute my Makefile same as Linux.
First check if mingw32-make is installed on your system.
Use mingw32-make.exe command in windows terminal or cmd to check,
else install the package mingw32-make-bin.
then go to bin directory default ( C:\MinGW\bin) create new file make.bat
#echo off
"%~dp0mingw32-make.exe" %*
add the above content and save it
set the env variable in powershell
$Env:CC="gcc"
then compile the file
make hello
where hello.c is the name of source code
Please learn about automake and autoconf.
Makefile.am is processed by automake to generate a Makefile that is processed by make in order to build your sources.
http://www.gnu.org/software/automake/
I found a very good example here: https://bigcode.wordpress.com/2016/12/20/compiling-a-very-basic-mingw-windows-hello-world-executable-in-c-with-a-makefile/
It is a simple Hello.c (you can use c++ with g++ instead of gcc) using the MinGW on windows.
The Makefile looking like:
EXECUTABLE = src/Main.cpp
CC = "C:\MinGW\bin\g++.exe"
LDFLAGS = -lgdi32
src = $(wildcard *.cpp)
obj = $(src:.cpp=.o)
all: myprog
myprog: $(obj)
$(CC) -o $(EXECUTABLE) $^ $(LDFLAGS)
.PHONY: clean
clean:
del $(obj) $(EXECUTABLE)
I am trying to install pngnq, which relies on libpng >= 1.2.8. I have installed libpng 1.5.7 via ./configure, make, sudo make install (without problems), because the libpng version in the Software Center was too old. I am now trying to install pngnq via ./configure, make, sudo make install (again, because Software Center version is too old), but am getting stuck at the make step on error messages which I believe pertain to libpng linking. A small sample of the error messages:
undefined reference to `png_destroy_write_struct'
undefined reference to `png_convert_from_time_t'
undefined reference to `png_set_PLTE'
I have limited experience with installing software manually on Linux, and so am not really sure what the next step is in diagnosing the problem. I've done substantial searching, but haven't really found anything targeted at the issue I'm having. Based on a forum post on a similar-ish issue I've done an ls on /usr/local/lib directory and found:
libpng15.a libpng15.so.15 libpng.la libpng15.la
libpng15.so.15.7.0 libpng.so libpng15.so libpng.a
though I don't know if that's actually any use in diagnosing/ruling out certain problems. Can anyone advise what might be wrong, keeping in my my minimal experience with compiling code on Linux?
Edit:
As requested, here is a sample of the trace beginning at the make call:
bryce#whatever:~/Downloads/pngnq-1.1$ make
Making all in src
make[1]: Entering directory `/home/bryce/Downloads/pngnq-1.1/src'
make all-am
make[2]: Entering directory `/home/bryce/Downloads/pngnq-1.1/src'
gcc `libpng-config --I_opts` -Wall --pedantic -std=gnu99 -g -O2 `libpng-config
--ldflags` -lz -o pngnq pngnq.o neuquant32.o rwpng.o -lm -lz
pngnq.o: In function `pngnq':
/home/bryce/Downloads/pngnq-1.1/src/pngnq.c:518: undefined reference to `png_get_gAMA'
Sounds like includes don't match the library. Double check to see if you've got png.h in /usr/include or libpng* in /usr/lib/.
Also show the gcc line that shows up before you see the error. That might point to the issue.