I am trying to compile and link a small C benchmark with floating-point operations for a MIPS target. The floating-point emulation library used with the benchmark is the SoftFloat. http://www.jhauser.us/arithmetic/SoftFloat.html
The MIPS compiler is an LLVM retargetted MIPS compiler release by MIPS Technologies: http://www.imgtec.com/mips/developers/clang-llvm.asp
Compilation is successful with the main program and also the library files. However, during linking, an error is thrown:
softfloat-macros:70: undefined reference to `__ucmpdi2'
In my opinion, the SoftFloat library is already a comprehensive library of functions which does not require me to write any new ones. However, my conclusion may be inaccurate due to my limited knowledge in compiling and linking libraries.
My main questions are:
Can the SoftFloat library be incomplete for my target and do I need to write the missing function of __ucmpdi2? Or is there something else that I am missing?
Am I compiling or linking the SoftFloat library incorrectly?
Below is an excerpt of my Makefile. I hope someone can help point out in case there is something wrong.
FILENAME = dfadd
MARCH = -mips1
MIPSGCC = mips-linux-gnu-gcc
MIPSLD = mips-linux-gnu-ld
CFLAGS = -Wall -c -g -msoft-float -mno-abicalls -I. $(MARCH)
mips: softfloat-macros softfloat-specialize milieu.h softfloat.h SPARC-GCC.h softfloat.c dfadd.c
$(MIPSGCC) -$(OPT) $(CFLAGS) $(FILENAME).c
$(MIPSAS) -o boot.o boot.asm
$(MIPSLD) -Ttext 0 -eentry -Map $(FILENAME).map -s -N -o $(FILENAME).elf boot.o $(FILENAME).o
The commands executed and the error is thrown at linker stage:
mips-linux-gnu-gcc -O0 -Wall -c -g -msoft-float -mno-abicalls -I. -mips1 dfadd.c
mips-linux-gnu-as -o boot.o boot.asm
mips-linux-gnu-ld -Ttext 0 -eentry -Map dfadd.map -s -N -o dfadd.elf boot.o dfadd.o
dfadd.o: In function `shift64RightJamming':
/home/jon/Work/bennchmark/dfadd/softfloat-macros:70: undefined reference to `__ucmpdi2'
make: *** [mips] Error 1
Related
I'm working on a Linux project in C consisting of two different open source applications. "Project A" (libduo) creates an archive used for linking a couple test programs and creates the library like this:
/usr/bin/ar rv libduo.a duo.o http_parser.o https.o match.o parson.o urlenc.o
/usr/bin/ar: creating libduo.a
a - duo.o
a - http_parser.o
a - https.o
a - match.o
a - parson.o
a - urlenc.o
ranlib libduo.a
One of the libduo test programs is built like this:
gcc -g -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -I. -I. -DDUODIR=\"/usr/local/duo/libduo/etc\" -DHAVE_CONFIG_H -c test-duologin.c
gcc -o test-duologin test-duologin.o -L. -lduo -lssl -lcrypto
"Project B" is an OpenLDAP module which I've built with -lduo and a few options to tell it where to find things:
(cd .libs && rm -f pw-apr1.la && ln -s ../pw-apr1.la pw-apr1.la)
../../../libtool --mode=compile gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -fPIC -DPIC -o .libs/pw-duo.o
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -o pw-duo.o >/dev/null 2>&1
../../../libtool --mode=link gcc -g -O2 -Wall -version-info 0:0:0 \
-rpath /usr/local/libexec/openldap -module -o pw-duo.la pw-duo.lo libduo.a -lduo
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
cc -shared .libs/pw-duo.o libduo.a -lduo -Wl,-soname -Wl,pw-duo.so.0 -o .libs/pw-duo.so.0.0.0
/usr/bin/ld: libduo.a(duo.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
libduo.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:51: recipe for target 'pw-duo.la' failed
make: *** [pw-duo.la] Error 1
The Makefile I'm using is the same one distributed with the OpenLDAP project. I've just added a section in the Makefile to build my module, using the same options for the other modules already there but adding -lduo to my section along with the paths to the libduo includes and libduo.a.
As make suggests above, I've recompiled by adding -fPIC after the -Wall option but it the same error was repeated. As a last resort, I tried adding -static to the module build but make was having none of that either:
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
This is the first time I've tried to build a C application against a lib not in the standard Linux locations so not exactly sure what's going on. I suspect libduo is built intended to be statically linked into everything, but the OpenLDAP modules are designed to use shared libraries. Can anyone elucidate?
Update: with help of comments below and this link I created a shared library from the .o files and distributed/built against that.
I do not know gcc and c well. In my /home/pi/Desktop/intern/adis16227_generic directory I have following 5 files.
ADIS16227.c
ADIS16227.h
Communication.c
Communication.h
main.c
main.c
#include<stdio.h>
#include "Communication.h" // Communication definitions.
int main() {
printf("hello!!\n");
unsigned char status = 0;
status = SPI_Init(0, 1000000, 1, 1);
printf("%u", status);
return 0;
}
Run command:
$ sudo gcc -L /home/pi/Desktop/intern/adis16227_generic main.c -lCommunication
Error:
/usr/bin/ld: cannot find -lCommunication
collect2: error: ld returned 1 exit status
Question:
What I am missing here?
What do I need to run the code?
-l is for libraries, and you never built a library from your Communication.c. The simplest solution is just add Communication.c to your compiler command line.
For larger projects, compile each translation unit separately with the -c switch like this:
gcc -c -Wall -Wextra -pedantic -omain.o main.c
gcc -c -Wall -Wextra -pedantic -oCommunication.o Communication.c
and so on ... (as a suggestion, I added some common warning options here, they help you spot errors)
The resulting .o files are object code. That's already compiled machine code, but with meta-information needed for a linker to link it with other object code into a complete executable.
Then link them all with one command:
gcc -oprogram main.o Communication.o
If you actually want a library from -- say -- Communication.c and ADIS16227.c, you could compile both to object code:
gcc -c -Wall -Wextra -pedantic -oCommunication.o Communication.c
gcc -c -Wall -Wextra -pedantic --oADIS16227.o ADIS16227.c
and then use ar to create a static library from them:
ar rcs libCommunication.a Communication.o ADIS16227.o
Then your initial compiler command would work (with the -lCommunication switch).
Final piece of advice: Never compile as root. This is completely unnecessary. So remove your sudo here.
those options:
-L /home/pi/Desktop/intern/adis16227_generic -lCommunication
suggest that the linker should find libCommunication.a (or .so) in the /home/pi/Desktop/intern/adis16227_generic directory.
But there are only sources in this directory. The linker won't build the sources of your "Communication" library for you.
So you could build the library and link with it:
gcc -c ADIS16227.c Communication.c
ar r libCommunication.a ADIS16227.o Communication.o
but maybe the fastest & quickest way to achieve a successful build would be:
sudo gcc -o main *.c
so it compiles all the files of the directory into the executable called main
Of course, it makes compilation times longer, but maybe it's not noticeable.
First move into the /home/pi/Desktop/intern/adis16227_generic directory:
cd /home/pi/Desktop/intern/adis16227_generic
Then, compile the source:
gcc ADIS16227.c Communication.c main.c -I .
You can now run your compiled program (called by default a.out):
./a.out
You have to compile separatedly files and then compile main with related obj file.
gcc -c Communication.c Communication.h
gcc main.c Communication.o -o main
My teacher is not the best at explain C so I'm having a bit of trouble understanding the connection of makefiles. I have already added the code for complex.c, complex.h, and main.c. I'm just having trouble compiling it all using the make command. I followed the example on the powerpoint he handed up and I don't understand why its failing to get to complex.
makefile
complex: main.o complex.o
gcc -o complex main.o complex.o
main.o: main.c complex.h
gcc -c main.c -lm
complex.o: complex.c complex.h
gcc -c complex.c -lm
clean:
rm*.o complex
ls
main.o
main.o: complex.h
gcc -c main.c
complex.o
complex.o: complex.h
gcc -c complex.c
Error
mason% make
gcc -o complex main.o complex.o
ld: fatal: file main.o: unknown file type
ld: fatal: file processing errors. No output written to complex
collect2: error: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `complex'
It looks like you have put Makefile fragments inside main.o and complex.o. These should be generated by the compiler, not by you.
Delete these files, and make again.
Additionally, your make clean rule is missing a space.
clean:
rm *.o complex
ls
One more thing. No need for -lm in the compile lines.
main.o: main.c complex.h
gcc -c main.c
complex.o: complex.c complex.h
gcc -c complex.c
You should add -lm at the linking phase.
complex: main.o complex.o
gcc -o complex main.o complex.o -lm
The "Makefile" defines and controls the build dependencies.
For example, you can't build the main executable binary without first building the binary object/module files that go with it. In this case, those are main.o and complex.o.
Generally any object file you need also needs a rule (though some rules can use "wildcards" to build more).
This is all rather academic. Best to take errors at their word and try to disprove them (this one basically says that main.o exists and is incorrect). In this case the hypothesis that main.o exists is supported by the fact that it didn't compile when you ran the make command.
Until you learn more you could invoke "make" using "targets". Like: make clean and make complex. It might help bring clarity.
A lot of makefiles put an "all" target to sort of reset the build. That then depends on "clean" and the executable and library targets. Like:
all: clean complex
So then you "make all" to clean and build.
A good tutorial is here. Mrbook Makefile Tutorial
I'm trying to compile a few .c files that used msgpack-c functions into a shared library. I have the following Makefile:
MSGPACK_CS = msgpack.c
CFLAGS = -std=c99
MSGPACK_OBJECTS = $(subst .c,.o,$(MSGPACK_CS))
MSGPACK_LIBS = msgpack.so
all: $(MSGPACK_OBJECTS) $(MSGPACK_LIBS)
%.o: %.c
$(CC) -c -shared -fPIC $(CFLAGS) $<
$(MSGPACK_LIBS): $(MSGPACK_OBJECTS)
ld -Lmsgpack/.libs -share -o $# $(MSGPACK_OBJECTS) -lmsgpack
I can compile a program that uses msgpack without problem, but this gives me the following error:
msgpack.o: In function `msgpack_pack_int64':
/usr/local/include/msgpack/pack_template.h:373: undefined reference to `__stack_chk_fail_local'
ld: msgpack.so: hidden symbol `__stack_chk_fail_local' isn't defined
ld: final link failed: Bad value
Apparently the linkage process isn't going well, but I don't know what is wrong. What can I do?
Try linking with the gcc driver instead of calling ld directly. ld doesn't know about the gcc support libs that are needed for the C runtime:
gcc -Lmsgpack/.libs -shared -o $# $(MSGPACK_OBJECTS) -lmsgpack
If this still doesnt't work, you might need to add -fno-stack-protector to your CFLAGS to supress runtime stack checking.
I'm developing a basic kernel for my term project. Until now, I haven't used any standard libraries in my project but I needed gets(), I included <stdio.h>. GCC finds the header location but the linker gives error :
ld -melf_i386 -Tlink.ld -o kernel boot.o main.o monitor.o common.o descriptor_tables.o isr.o interrupt.o gdt.o timer.o
main.o: In function `main':
main.c:(.text+0x53): undefined reference to `gets'
This is my Makefile file,
SOURCES=boot.o main.o monitor.o common.o descriptor_tables.o isr.o interrupt.o gdt.o timer.o
CFLAGS= -m32 -fno-stack-protector -fstack-check
LDFLAGS= -melf_i386 -Tlink.ld
ASFLAGS=-felf
all: $(SOURCES) link
clean:
-rm *.o kernel
link:
ld $(LDFLAGS) -o kernel $(SOURCES)
.s.o:
nasm $(ASFLAGS) $<
You cannot use the C library for a kernel as it is build for an existing kernel and relies on the syscalls of its target OS. Instead, you have to write a driver for keyboards and everything else you need to get characters from anywhere. getc() is a very advanced function from that point of view and you should consider making the basic functions of the kernel stable before programming anything to interact with.
By the way, you should really build a cross compiler. It has many advantages over feeding the system compiler with awkward options. After all, the kernel is meant to run on different machines, so it should be compiled for bare x86, which is what a cross-compiler does.
Keep coding this thing!
leitimmel