I'm trying to create a shared library with my gcc. It's a gcc for vxworks (thats probably the problem...).
I use the gcc as following:
./gcc -shared -B/path/to/gnutools/bin -o test.so test.c
Result:
/path/to/ld: -r and -shared may not be used together
collect2: ld returned 1 exit status
If I try the same with the linux gcc, there's no problem. So i guess the gcc for VxWorks automatically passes the -r (or -i, which is the same and results in the same) flag to the linker. Is there a way to suppress this?
Greetz
marty
PS: making it static is not really an alternative...
Try compile object file separately with -fPIC and then link:
gcc -Wall -fPIC -c -o test.o test.c
gcc -Wall -shared -o test.so test.o
Another suggestion is to use libtool (at least to figure out the correct flags).
A workaround may be to go directly with ld:
ld -shared -o test.so test.o -lc
Related
I am using GCC to compile a program for an Atmel Cortex M4 SAM4S Processor. I need to link the standard libraries libgcc.a and libc.a, and to do so I am currently using the following makefile commands
LIBDIR1=C:/Program\ Files\ \(x86\)/GNU\ Arm\ Embedded\ Toolchain/10\ 2020-q4-major/arm-none-eabi/lib/thumb/v7e-m/nofp
LIBDIR2=C:/Program\ Files\ \(x86\)/GNU\ Arm\ Embedded\ Toolchain/10\ 2020-q4-major/lib/gcc/arm-none-eabi/10.2.1/thumb/v7e-m/nofp
ld_input=linker.ld startup.o main.o syscalls.o
ld_flags=-L$(LIBDIR1) -L$(LIBDIR2) -lm -lc -lgcc
out.elf: $(ld_input)
arm-none-eabi-ld -o out.elf -T $(ld_input) $(ld_flags)
However, to link to the correct multilib, I need to specify the subdirectories /thumb/v7e-m/nofp explicitly, which I determined via
arm-none-eabi-gcc -mcpu=cortex-m4 --print-multi-dir
Is there a way to link to the correct subdirectories automatically, based on the -mcpu=cortex-m4 option?
It seems everything works by using gcc instead of ld for linking. gcc then calls the linker with all the correct options, including all the standard librarier automatically.
The code shown in the question can be replaced by
ld_input=linker.ld startup.o main.o syscalls.o
out.elf: $(ld_input)
arm-none-eabi-gcc -mcpu=cortex-m4 -o out.elf -T $(ld_input)
I'm trying to link a static library archive file (libx/libx.a) with a C code. The library requires 2 flags (-lx -lpthread). After linking the static library my ultimate goal is to create a shared library. I have the following Make file,
rsa-engine: rsa/rsa.c rsa/bignum.c rsa/aes.c rsa/x509parse.c rsa/pem.c
gcc -fPIC -o rsa/rsa.o -c rsa/rsa.c
gcc -fPIC -o rsa/bignum.o -c rsa/bignum.c
gcc -fPIC -o rsa/aes.o -c rsa/aes.c
gcc -fPIC -o rsa/x509parse.o -c rsa/x509parse.c
gcc -fPIC -o rsa/pem.o -c rsa/pem.c
gcc -fPIC rsa-engine.c libx/libx.a -L.libx/ -lx -lpthread -o rsa-engine.o
gcc -shared -o librsa_engine.so -lcrypto rsa-engine.o rsa/rsa.o rsa/bignum.o rsa/aes.o rsa/x509parse.o rsa/pem.o
clean:
rm -f *.o rsa/*.o *.so rsa-engine
After using the make command it produces the following output,
/usr/bin/ld: cannot find -lx
collect2: error: ld returned 1 exit status
Makefile:2: recipe for target 'rsa-engine' failed
make: *** [rsa-engine] Error 1
I found similar questions here. But that did not help. Seems like I can't make the link work. Any help with what I'm doing wrong?
I would like to achieve the same result generated by the following command,
CC := gcc
CFLAGS := -Wall -g -MD -O2 -I ../
LDFLAGS := -lx -lpthread
tests_files := hello
all: $(tests_files)
hello: hello.o ../libx/libx.a
$(CC) $(CFLAGS) -static $(<) -L../libx/ $(LDFLAGS) -o $(#)
It seems that your libx.a is located in libx, yet -L references .libx directory. Anyway, since you reference libx/libx.a directly, you may skip both -L.libx/ -lx and it should link just fine.
During installation of pintos, I had to run make.
Following is the Makefile.
all: setitimer-helper squish-pty squish-unix
CC = gcc
CFLAGS = -Wall -W
LDFLAGS = -lm
setitimer-helper: setitimer-helper.o
squish-pty: squish-pty.o
squish-unix: squish-unix.o
clean:
rm -f *.o setitimer-helper squish-pty squish-unix
In one computer it executed correctly. (output for the command is given below)
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
gcc -lm setitimer-helper.o -o setitimer-helper
gcc -Wall -W -c -o squish-pty.o squish-pty.c
gcc -lm squish-pty.o -o squish-pty
gcc -Wall -W -c -o squish-unix.o squish-unix.c
gcc -lm squish-unix.o -o squish-unix
but in other computer I got the following error
gcc -lm setitimer-helper.o -o setitimer-helper
setitimer-helper.o: In function `main':
setitimer-helper.c:(.text+0xc9): undefined reference to `floor'
collect2: error: ld returned 1 exit status
<builtin>: recipe for target 'setitimer-helper' failed
make: *** [setitimer-helper] Error 1
If looked at first line of outputs of both make commands
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
and
gcc -lm setitimer-helper.o -o setitimer-helper
They are different.
Why make is executing different commands for the same Makefile? and What should I do to remove error?
In the first computer, the setitimer-helper.o file either doesn't exist or the setitimer-helper.c file is newer, so make needs to rebuild it. Thus it runs the compiler, then afterwards it performs the link operation:
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
gcc -lm setitimer-helper.o -o setitimer-helper
On the second computer, the setitimer-helper.o file already exists and is newer than the setitimer-helper.c file, so the compile command was not needed and the second computer proceeded directly to the link line:
gcc -lm setitimer-helper.o -o setitimer-helper
The real question is why you got the linker error on the second computer.
The answer to that is that the -lm flag needs to come on the linker line after the object files. This happens because you added -lm to the LDFLAGS variable which is not the right one: that should contain options that tell the linker where to look for files, etc. (for example, the -L option).
Libraries should be added to the LDLIBS variable, not LDFLAGS. Change your makefile to this:
all: setitimer-helper squish-pty squish-unix
CC = gcc
CFLAGS = -Wall -W
LDLIBS = -lm
setitimer-helper: setitimer-helper.o
squish-pty: squish-pty.o
squish-unix: squish-unix.o
clean:
rm -f *.o setitimer-helper squish-pty squish-unix
Your link line will then look like:
gcc setitimer-helper.o -o setitimer-helper -lm
and should work properly.
I'm trying to compile a c++ program and I am having some issues. In particular, when I use x86_64-w64-mingw32-gcc as my compiler, it complains half way through my compilation saying "tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized".
Here is my makefile (not mine, I'm trying to adapt this makefile to a cygwin environment) https://pastebin.com/vgnVYJUL
Here is the console output when I run make:
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver.cpp.o src/libfastms/solver/solver.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_base.cpp.o src/libfastms/solver/solver_base.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_host.cpp.o src/libfastms/solver/solver_host.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/has_cuda.cpp.o src/libfastms/util/has_cuda.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/image_mat.cpp.o src/libfastms/util/image_mat.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
ld -r -o tmp/src/libfastms/libfastms.o tmp/src/libfastms/solver/solver.cpp.o tmp/src/libfastms/solver/solver_base.cpp.o tmp/src/libfastms/solver/solver_host.cpp.o tmp/src/libfastms/util/has_cuda.cpp.o tmp/src/libfastms/util/image_mat.cpp.o
tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized
Makefile:167: recipe for target 'tmp/src/libfastms/libfastms.o' failed
make: *** [tmp/src/libfastms/libfastms.o] Error 1
Some other notes:
I don't have this problem when I compile with g++ (only seems to be minGW)
A common solution to this problem is to clean the directory of residual object files. This does not work.
Another common reason for this is trying to compile .h files. Obviously I am not doing this.
Thanks in advance.
You are compiling your object files with a 64-bit compiler driver, w64-mingw32-gcc,
and with -m64 you are explicitly directing it to generate 64-bit code (unnecessarily,
as that is its default). But you are linking with a 32-bit linker that does not
understand 64-bit object files.
This is happening because in your makefile you are, unusually, invoking ld
explicitly for your incremental solver linkage:
COMMAND_LINK_SOLVER=ld -r -o $# $^
rather than delegating linkage to your compiler driver in the usual way, and
a 32-bit ld from a different toolchain is being found in your PATH before
the 64-bit one belonging to your mingw-w64 toolchain.
To avoid this, invoke the linker via the compiler driver as normal, which for your
solver linkage means:
COMMAND_LINK_SOLVER=$(GXX) -Wl,-r -o $# $^
You can depend on w64-mingw32-gcc to invoke the ld that was installed with it.
There is no need to correct your main linkage as it is already done the right way.
I want to create static library and something goes wrong. I have makefile:
static: main.c tree.c
gcc -c -Wall tree.c -o tree.o
ar crs libtree.a tree.o
gcc -Wall -static main.c -L. -ltree -o main
./main
When I write "make static", it shows me:
gcc -c -Wall tree.c -o tree.o
ar crs libtree.a tree.o
gcc -Wall -static main.c -L. -ltree -o main
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [static] Error 1
It created files: tree.o and libtree.a. I don't know why it doesn't want to find a library. Do you know how to solve it?
Most probably, your system is not set up for static linking. Most newer Linux distributions aren't as static linking is highly discouraged.
Look for a package named glibc-static or similar and install.
In case your system is not Linux (could be MacOS X as well, you didn't state that) - You're doomed. Static linking is not supported on that platform at all.