I am interested in including C++ language in my c based program. I have two systems (Host and Target) which target system is limited, especially in memory. So, in my host machine, I have to statically link some libraries which will be needed by the program on target side. However, in my makefile I have been manipulating gcc patch (using a variety of gcc flags, during both compiling and linking steps).
Everything is ok until using C++ language;
For example, By including iostream header file in .cpp file, there exist an error on the target system showing that : "can not resolve symbol 'wctob' "
I must indicate my makefile as bellow:
in the compiling step:
$(CXX) -O0 -I<Headers dir> $(LIBSC) -Wno-write-strings -Wno-narrowing -Wno-return-type -Wno-abi -Wno-unused-variable -DNDEBUG -Wa, -c -fmessage-length=0 -I<Headers dir> -march=4kec -EL -o "$#" "$<"
in the linking step:
$(CXX) -lpthread -Wl,-Map,output.map $(MyFlags) $(LIBS) $(STRIP) -muclibc -march=4kec -EL -o
"output.elf" $(OBJS) $(LIBS) $(MyFlags) -Wl,-rpath -Wl,<LIBDIR> -L<LIBDIR>
------some definitions
MyFlags = -lc -static-libstdc++ -static-libgcc;(such flags used in the linking step)
LIBDIR = is the address of needed libraries
LIBSC = -nostdinc++ ;(such flags used in the compiling step)
Headers dir = is the address of needed both c and c++ header files included by the programmer.
LIBS and OBJS are also the list of needed libraries and objects.
Also, I added LIBDIR to ld.so.conf and LD_LIBRARY_PATH, but the problem is not solved far away. (My g++ version is 4.7.3.)
Can anybody help me out?
You have to tell C++ compiler to use C naming and symbols. so :
extern "C" {
// your cpp codes
}
Related
I am having issues linking a library (termbox) when compiling. I get the error:
make: *** No rule to make target `termbox.h', needed by `test.o'. Stop.
Makefile:
edit: test.o
gcc -Wall -o edit test.o
test.o: test.c termbox/src/termbox.h
gcc -Wall -c test.c -ltermbox/src
Include:
#include "termbox/src/termbox.h"
I have also tried using the compiled library but ran into similar issues. Do I have to use some sort of combination of specifying the header file and the location of the compiled library?
The directory of my termbox folder is in the same directory as test.c.
Thanks!
You have managed to compile and include the header file for the library, but you did not yet tell the compiler where the code (definitions) are - i.e. you did not tell it to link in the library yet.
You will need to do that next, this is done in a similar way to telling the linker what files to link, but with some extra syntax. It appears to be a static library (.a suffix) so you can link like this:
test.o: test.c termbox/src/termbox.h
gcc -Wall -c test.c -Itermbox/src -Lsrc -ltermbox
Where -L... specifies where libraries can be found and -l... specifies the library name to link to minus the lib prefix and the .a or .so suffix. Also note that order is important, so leave the library linkage at the end.
More on library linking order here
UPDATE
Sorry I added the linking to the wrong line! - here is the updated answer:
# The linker stage
edit: test.o
gcc -Wall -o edit test.o -Lsrc -ltermbox
# Compile stage
test.o: test.c termbox/src/termbox.h
gcc -Wall -c test.c -ltermbox/src
Is it possible to configure automake to generate a Makefile which, in addition to building the .o files and linked binary, also has targets for %.s? I want to be able to review the compiler output in a text format without having to invoke binutils on the .o files.
Specifically, if I have main.c as a source file, I want to be able to run make main.s. The desired recipe would be the same as that for main.o, but using CC1 := $(CC) -S.
The question is a little XY.
You want to be able make the intermediate assembly file foo.s, where
the source file foo.c is one of the sources in an autotooled project, using
a makefile that is generated by the project's ./configure script. You
assume that to do this you must do something to the automake inputs -
the Makefile.ams? - that will cause ./configure to generate Makefiles
that include assembly targets *.s matching all object targets *.o.
Well you could, but then your project would not be a regular autotooled
project as usually distributed, and there is no need to make it irregular
to get what you want.
The GCC option -save-temps
exists to let developers see the intermediate files of compilation - the preprocessor
output, the assembly.
$ gcc -c -o foo.o foo.c
outputs foo.o
$ gcc -save-temps -c -o foo.o foo.c
outputs:
foo.o
foo.i # preprocessed source
foo.s # assembly
As I expect you know, GNU Make receives compiler options from the make-variable
CFLAGS, and automake respects this convention, independently of and in addition to any compiler
options prescribed by the project's autotooling. So, if you would otherwise generate
makefiles with:
$ ./configure ...
then, to add -save-temps to the C compiler options, generate makefiles instead
with:
$ ./configure CFLAGS=-save-temps ...
And if you are already using CFLAGS, e.g.
$ ./configure CFLAGS="-g -O0" ...
then append -save-temps:
$ ./configure CFLAGS="-g -O0 -save-temps" ...
Then,
$ make main.o
will make main.o, main.i and main.s up-to-date.
To disable -save-temps, of course, rerun ./configure, removing it from
the CFLAGS.
If the project involves C++ compilation, then CXXFLAGS affects the C++
compiler in the same way that CFLAGS affects the C compiler. Note that
the generated preprocessed C++ sources will be called *.ii, not *.i.
With -save-temps enabled, make clean will not delete the *.i and *.s
files. You may not care, since compilation will always clobber them. If you
do care, you may take advantage of automake's standard phony target clean-local,
which is supported to let an autotooling maintainer extend the behaviour of
clean. Add the following recipe to the Makefile.am of each source directory
in the project:
clean-local:
$(RM) *.i *.ii *.s
Then update the autotooling and regenerate Makefiles:
$ autoreconf
$ ./configure ...
While the COMPILE variable in the generated Makefile.in is technically an internal detail, and this solution relies on the compiler to understand -c -S, adding:
.c.s:
$(COMPILE) -c -S $<
to the Makefile.am has worked for as long as I've been using the autotools. It might also be convenient to add:
clean-local:
rm -f *.s
I find this useful in development to have a look at the assembly output for specific configure and CC, CFLAGS options.
The COMPILE variable will be defined as something like:
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
Similarly, for C++ source we have:
.cc.s:
$(CXXCOMPILE) -c -S $<
I have application test.c which by using gcc on host(on ubuntu) machine i have succeed in compilation and successfully ran the application program on host.
now I would like to cross compile the same application with arm-cross compiler for LPC1788. please guide me how to link the openssl library files
My Mkakefile with GCC
CC = gcc
CFLAGS = -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_XKMS=1
-DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1 -I/usr/include/xmlsec1
-I/usr/include/libxml2 -DXMLSEC_OPENSSL_097=1
-DXMLSEC_CRYPTO_OPENSSL=1 -DXMLSEC_CRYPTO=\"openssl\ -DUNIX_SOCKETS -D XML_SECURITY
LDFLAGS = -lcrypto -I/usr/include/libxml2 -lxml2 -I/usr/include/xmlsec1 -lxmlsec1
all:
$(CC) src/test.c -o test $(CFLAGS) $(LDFLAGS)
by changing the compiler I used the following Makefile
CC = /home/amarayya/doc/tools/arm-2010q1/bin/arm-uclinuxeabi-gcc
CFLAGS = -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_XKMS=1
-DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1 -I/usr/include/xmlsec1
-I/usr/include/libxml2 -DXMLSEC_OPENSSL_097=1
-DXMLSEC_CRYPTO_OPENSSL=1 -DXMLSEC_CRYPTO=\"openssl\ -DUNIX_SOCKETS -D XML_SECURITY
LDFLAGS = -lcrypto -L/usr/include/libxml2 -lxml2 -L/usr/include/xmlsec1 -lxmlsec1
all:
$(CC) src/test.c -o test $(CFLAGS) $(LDFLAGS)
which leading to these errors
fatal error: openssl/rsa.h: No such file or directory
fatal error: openssl/rsa.h: No such file or directory
what causing these errors and how to over come
You cannot use your host libraries when compiling for a different architecture. First, you need to cross compile all non-standard libraries (libxml, libopenssl) for your target machine (i.e. ARM).
Basically, you need to download the source code for these libraries and configure it with
--host=arm-uclinuxeabi --prefix=SOME_HOST_DIR
(or something similar - you might check the README files)
assuming, that you have your cross compiler in PATH.
These libraries might also require more libraries to be cross compiled.
When compiling your application you should use these cross compiled libraries.
I have the following makefile
CXXFILES = pthreads.cpp
CXXFLAGS = -O3 -o prog -rdynamic -D_GNU_SOURCE -L./libmine
LIBS = -lpthread -ldl
all:
$(CXX) $(CXXFILES) $(LIBS) $(CXXFLAGS)
clean:
rm -f prog *.o
I am trying to include the ./libmine library within CXXFLAGS, but it seems like it is not the right way to include a static library, because when I compile the program, I get many undefined references error. So what is actually the right way to include a static library in the makefile?
use
LDFLAGS= -L<Directory where the library resides> -l<library name>
Like :
LDFLAGS = -L. -lmine
for ensuring static compilation you can also add
LDFLAGS = -static
Or you can just get rid of the whole library searching, and link with with it directly.
Say you have main.c, fun.c and a static library libmine.a.
Then you can just do in your final link line of the Makefile
$(CC) $(CFLAGS) main.o fun.o libmine.a
CXXFLAGS = -O3 -o prog -rdynamic -D_GNU_SOURCE -L./libmine
LIBS = libmine.a -lpthread
Make sure that the -L option appears ahead of the -l option; the order of options in linker command lines does matter, especially with static libraries. The -L option specifies a directory to be searched for libraries (static or shared). The -lname option specifies a library which is with libmine.a (static) or libmine.so (shared on most variants of Unix, but Mac OS X uses .dylib and HP-UX used to use .sl). Conventionally, a static library will be in a file libmine.a. This is convention, not mandatory, but if the name is not in the libmine.a format, you cannot use the -lmine notation to find it; you must list it explicitly on the compiler (linker) command line.
The -L./libmine option says "there is a sub-directory called libmine which can be searched to find libraries". I can see three possibilities:
You have such a sub-directory containing libmine.a, in which case you also need to add -lmine to the linker line (after the object files that reference the library).
You have a file libmine that is a static archive, in which case you simply list it as a file ./libmine with no -L in front.
You have a file libmine.a in the current directory that you want to pick up. You can either write ./libmine.a or -L . -lmine and both should find the library.
The -L merely gives the path where to find the .a or .so file. What you're looking for is to add -lmine to the LIBS variable.
Make that -static -lmine to force it to pick the static library (in case both static and dynamic library exist).
Addition: Suppose the path to the file has been conveyed to the linker (or compiler driver) via -L you can also specifically tell it to link libfoo.a by giving -l:libfoo.a. Note that in this case the name includes the conventional lib-prefix. You can also give a full path this way. Sometimes this is the better method to "guide" the linker to the right location.
I am working on embedded software for a ARM microcontroller (SAM7) and using Yagarto toolchain.
My code currently links libc.a. However I'd like to use a custom implementation of the builtin function memcpy that my code already has.
I have tried using -fno-builtin and/or -fno-builtin-memcpy as specified in the GCC Manual but the linker still complains will the following warning:
contiki-crazy-horse.a(flashd_efc.o): In function `memcpy':
C:\Users\Melvin\GitRepo\projects\Amatis_Project\SAM7_Contiki\examples\er-rest-example/../../cpu/arm//at91sam7s-x/./flashd_efc.c:669: multiple definition of `memcpy'
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-memcpy.o):C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\string/../../../../../newlib-1.19.0/newlib/libc/string/memcpy.c:78: first defined here
collect2: ld returned 1 exit status
make: *** [rest-server-example-nosyms.crazy-horse] Error 1
../../cpu/arm/at91sam7s-x/Makefile.at91sam7s-x:181: recipe for target `rest-server-example-nosyms.crazy-horse' failed
What is the correct way to use custom implementations of certain gcc built-in functions?
Edit 1: Adding the linking command I am using. In the code below Porject.a is an archive file created with all the project's object files.
CC = arm-none-eabi-gcc
CFLAGSNO = -I. -I$(CONTIKI)/core -I$(CONTIKI_CPU) -I$(CONTIKI_CPU)/loader \
-I$(CONTIKI_CPU)/dbg-io \
-I$(CONTIKI)/platform/$(TARGET) \
${addprefix -I,$(APPDIRS)} \
-DWITH_UIP -DWITH_ASCII -DMCK=$(MCK) \
-Wall $(ARCH_FLAGS) -g -D SUBTARGET=$(SUBTARGET)
CFLAGS += $(CFLAGSNO) -O -DRUN_AS_SYSTEM -DROM_RUN -ffunction-sections
LDFLAGS += -L $(CONTIKI_CPU) --verbose -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map
$(CC) $(LDFLAGS) $(CFLAGS) -nostartfiles -o project.elf -lc Project.a
If it is finding memcpy() in libc.a, then it is not conflicting with any "built-in", but rather with the newlib implementation. You may need also to specify -nostdlibs option and explicitly link libc.a and libm.a as necessary.
Object (.o) files are linked before library archives (.a) files are searched, so if a symbol is resolved by an object file, it will not be searched for in the archives. If you place your overrides in an static-link library, then you simply list it ahead of the standard library (or any other libraries that use the standard library) on the linker command line.
[Added] The following was originally a "comment" but should probably be in the answer; it is in response to "Edit 1" in the question, and the comment below about link order:
Change -nostartfiles -o project.elf -lc Project.a to -nostdlib -o project.elf -start-group Project.a -lc -end-group. The switch -nostdlib disables default linking of both start-up files (i.e. -nostartfiles) and standard libraries. The library grouping causes the libraries in the group to be searched iteratively until no further symbols can be resolved, allowing out-of-order and circular dependencies like yours to be resolved. An alternative form for the grouping switches is -( Project.a -lc -).