I'm working on a project in which I'm using Micropython's minimal sample code for my STM32 board. The Micropython interpreter on my STM32 board runs without issues (I modified the low-level libraries). Now for customising Micropython and building a few modules which shall read some value from the local variables and load it to display. Hence, I'm trying to use the IO functions, i.e. sprintf( ), but unfortunately, my compiler arm-none-eabi-ld is throwing an error (given below).
arm-none-eabi-ld: build/modmyport.o: in function `board_clockinfo':
../micropython/ports/minimal/modmyport.c:46: undefined reference to `sprintf'.
At first, I thought that the flag in makefile -nostdlib prevents the compiler from using the regular standard libraries. But even after removing them, I still got the same error.
https://github.com/micropython/micropython/blob/master/ports/minimal/Makefile
#makefile in the minimal port, CROSS = 1
CFLAGS_CORTEX_M4 = -mthumb -mtune=cortex-m4 -mcpu=cortex-m4 -msoft-float -fsingle-precision-constant -Wdouble-promotion -Wfloat-conversion
CFLAGS += $(INC) -Wall -Werror -std=c99 -nostdlib $(CFLAGS_CORTEX_M4) $(COPT)
LDFLAGS += -nostdlib -T stm32f405.ld -Map=$#.map --cref --gc-sections
Moreover: I think that it might be some linking or definition-related issues.
/*Because in the code given below*/
int a = 5 ;
sprintf(buffer,"this is just for test\n\r"); /*This is working*/
sprintf(buffer,"this is just for test=%d\n\r",a); /*This is not working*/
Does anyone know what I can do to resolve this issue? Any hint or support is highly appreciated.
Related
I'm trying to compile and link some .c file. I have been using Eclipse IDE for C/C++ developers, and in my local machine i can compile without problems. However, when i try to compile and link the same file in a RedHat OS (gcc version is 4.9.2-6 in this OS) i'm having problems. I get some warnings at compile time, but those are fine, i think, i just ignored and the application still runs fine. Here are the commands i executed and the associated output:
gcc -O0 -g3 -Wall -c -fmessage-length=0 -std=c99 -MMD -MP -MF"example.d" -MT"example.d" -o "example.o" "example.c"
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
warning: implicit declaration of function ‘wait’ [-Wimplicit-function-declaration]
This generates two files, example.d and example.o. Then, i try to link them, without luck, with the following command:
gcc -Xlinker -L/usr/lib -lrt -static -pthread example.o -o example
/usr/bin/ld: cannot find -lrt
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
The commands are taken directly from the ones that Eclipse generates, and work just fine in my local computer (Ubuntu OS) but not in the RedHat environment. The last command didn't work, with and without the -L option. I suppose the directory in -L is fine, as i run, for example,
locate libpthread.so
And one of the locations i get is /usr/lib (also /usr/lib64, but neither work).
Any help will be greatly appreciated!! :)
If you try to link a static executable, it will look for the *.a versions of the libraries, not what you usually want. Remove the -static flag. Or you can install the static libraries if you really want to. It also should not be necessary to add -L/usr/lib explicitly.
In my latest project I am encountering a strange issue regarding an undefined reference to a method of a shared library. I searched on SO but all I could find was either C++ related (extern "C") or not really helping.
The library in question is my fork of libosm which uses protobuf to generate de-/serialization code for OpenStreetMap data in its binary format (.osm.pbf). The function in question is osmpbf__blob__unpack but that is just the first I end up using so I suspect its a general problem.
I inspected the resulting libosm.a with nm and the method is there and exported but for some reason it is not found while linking. Below are my current flags. I tried changing the order and even including all libraries twice (as suggested in another thread) but I always end up with the undefined reference.
CFLAGS = -v -std=c99 -O3 -Wall -Wextra -pedantic
LIBFLAGS = -losmpbf -lprotobuf-c -lz -lpthread
At the moment I am quite lost on what the error could be, but I think it might be a minor general error. It has been a while since I used C..
Any help would be appreciated.
Cheers,
Florian
Edit: Here is my complete Makefile. I just made up the name for the variable LIBFLAGS since I use my own little rule but it seems like I should use LDLIBS and the builtin rules for this simple case.
CC = gcc
CFLAGS = -v -std=c99 -O3 -Wall -Wextra -pedantic
LIBFLAGS = -losmpbf -lprotobuf-c -lz -lpthread
all: main.x
main.x: main.c
$(CC) $(CFLAGS) $(LIBFLAGS) main.c -o main.x
clean:
rm -rf *.o main.x
The problem is the linker (gcc), like most linkers, processes the parameters from left to right. so the link sees the libraries, but there is no unresolved references to be handled, so nothing happens.
The fix is to place the libraries last on the line rather than just after the CFLAGS.
Im wondering why Im getting no undefined references when compiling as a shared library using -shared as an option for gcc. Consider the following case:
#include <confuse.h>
int
main(int argc, char **argv)
{
cfg_opt_t opts[1];
cfg_t *cfg = cfg_init(opts, CFGF_NOCASE);
return 0;
}
libconfuse is needed here in order to run the program properly. If im compiling it as a "normal" application without specifying that libconfuse is needed (-lconfuse) im getting the following (from my perspective regular) error:
$ gcc -Wall -Wno-unused-variable test.c -o test
/tmp/ccTVz6an.o: In function `main':
test.c:(.text+0x20): undefined reference to `cfg_init'
collect2: error: ld returned 1 exit status
If im compiling the same code as a shared library im not getting any error message regarding the library:
$ gcc -Wall -Wno-unused-variable test.c -o test.so -shared
$ echo $?
0
Can someone please bring light into darkness?
You are compiling a (shared) library, not a program, and libraries are expected not to be complete, so undefined references do not prevent the shared library from building.
Yes, it may sound a bit surprising, particularly if you come from a OS (Windows?) where the shared libraries are always fully linked, but that's how ELF works.
If you want to ensure that all your references are are resolved when building a shared library you can use the linker option --no-undefined:
gcc -Wall -Wno-unused-variable test.c -o test.so -shared -Wl,--no-undefined
Note that libraries used to resolve references when linking a shared library will be added to the header of that library, as NEEDED entries, and then linked automatically when using that library. See objdump -p for details.
With shared libraries (not static ones), you could link a library libA.so into your other library libB.so.
So you could compile your shared library as:
gcc -Wall -Wno-unused-variable -fPIC test.c \
-o libmytest.so -shared -lconfuse
Later you would link that library to some main.c with
gcc -Wall main.c -lmytest -L. -o myprog
or you could load it at runtime, using dlopen(3) on ./libmytest.so (read the man page about why ./ is significant to dlopen)
Simple explanations are in the Program Library HowTo. But Drepper's paper: How to Write Shared Libraries is the best reference.
And it is permitted for a shared library (or even a static one) to have undefined references, since quite often the user of that library would explicitly link the lower level libraries needed by it.
I am failed to compile builtin example hwserver.c using ZeroMQ APIs. I have tried every possible way.
gcc -lzmq hwserver.c -o hwserver
It prompts me with:
hwclient.c:(.text+0x22): undefined reference to `zmq_ctx_new'
hwclient.c:(.text+0x3a): undefined reference to `zmq_socket'
hwclient.c:(.text+0x52): undefined reference to `zmq_connect'
hwclient.c:(.text+0x94): undefined reference to `zmq_send'
hwclient.c:(.text+0xb8): undefined reference to `zmq_recv'
hwclient.c:(.text+0xe4): undefined reference to `zmq_close'
hwclient.c:(.text+0xf0): undefined reference to `zmq_ctx_destroy'
collect2: error: ld returned 1 exit status
I'm using zeromq-3.2.2 on ubuntu-12.10
Any help really appreciated.
Thanks,
-Sam
Order of arguments to gcc does matter a lot.
Try
gcc -Wall -g hwserver.c -lzmq -o hwserver
You need first the warning and optimizations or debugging flags (e.g. -Wall for all warnings, -g for debugging information), then the optional preprocessor flags (like -D or -I but you have none of them), then the source files, and at last the libraries -lzmq (order is relevant: from high level libraries to low level ones) and the output option -o hwserver (which could be elsewhere).
Read the gcc documentation, notably the chapter about invoking GCC.
Don't forget the -Wall : you really want to get all warnings, and you should improve your code till no warnings are given. You could even want -Wextra to get more extra warnings.
Don't forget the debugging information flag -g: you will need to use the gdb debugger to debug your program.
Later, use -O or -O2 to optimize the binary program (the compiler will then produce more efficient, but less debuggable, machine code). Care about that only when your program is debugged.
As soon as you want to develop real-sized C programs (i.e. your project made of several source files and some header file[s]), you'll need a builder infrastructure, like GNU make (a very common builder; you could try omake instead).
See also this answer to a related question.
try again
gcc hwserver.c -o hwserver -lzmq
Your order of the parameters is incorrect.
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 -).