To link gcc statically into a shared library, based on the answer in this question, the remaining problem is how to let the linker use the PIC version of libc.a instead of the non-PIC version. The problem is the same as that answer:
g++ -fPIC -Wall -O0 -fexceptions -g -c main.cpp -o main.o
ld -shared -static -o test.so main.o -lc
ld: //usr/lib/x86_64-linux-gnu/libc.a(malloc.o): relocation R_X86_64_TPOFF32 against `tcache' can not be used when making a shared object; recompile with -fPIC
This is what I'v tried:
sudo apt-get install libc-pic //then libc6-pic get installed successfully
ld -shared -static -o test.so main.o -lc //same as above, same error
ld -shared -static -o test.so main.o -lc-pic //not working: cannot find -lc-pic
ld -shared -static -o test.so main.o -lc6-pic //not working: cannot find -lc6-pic
Looking at the list of files in the package there is a libc_pic.a so the correct option seems to be -lc_pic.
Related
For some reasons, I want to build a static shared library: a self sustain
library that without any external dependent library.
My build environment is alpine linux.
(I believe that gcc is /usr/bin/aarch64-alpine-linux-musl-gcc)
I build my shared library as follows:
gcc -fpic -c jpg_to_bmp.c -o jpg_to_bmp.o
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
gcc -I ./ -L ./ main.c -o main.o
However
LD_LIBRARY_PATH=`pwd` ./main test.jpg test.bmp
dies with Segmentation fault
if I link the shared library without -static -lc -lstdc++
ld -fpic -shared -static -lc -lstdc++ jpg_to_bmp.o FreeImage/Dist/libfreeimage.a -o libmy_img_static.so
Everything works fine.
How do I build a static shared library(self-sustain) using musl ?
Did I miss any step or flag ?
I'm currently playing around with LTO for an embedded system (to see if it could reduce the size) and was having some issues getting everything to link properly using ld directly and was wondering what I was doing wrong. This is mostly playing with a toy program before I use this in a larger project.
The setup is basically I have 3 files:
test.c - data transform function
test_main.c - calls a function defined in start.S
start.S - calls a function in test.c and also contains _start
I compile the files using:
arm-none-eabi-as -mthumb -Wall start.S -o start.o
arm-none-eabi-gcc -Wall -Werror -march=armv7 -mtune=cortex-r7 -mthumb -fPIC -nostdlib -flto -static test.c -c test.o
arm-none-eabi-gcc -Wall -Werror -march=armv7 -mtune=cortex-r7 -mthumb -fPIC -nostdlib -flto -static test_main.c -c test_main.o
If I then try to link the program with ld I get:
arm-none-eabi-ld --static -fPIC --shared --fatal-warning test.o start.o test_main.o -test
arm-none-eabi-ld: test.o: plugin needed to handle lto object
arm-none-eabi-ld: test.o: plugin needed to handle lto object
arm-none-eabi-ld: test_main.o: plugin needed to handle lto object
arm-none-eabi-ld: test_main.o: plugin needed to handle lto object
If I use gcc though, it works:
arm-none-eabi-gcc -Wall -Werror -march=armv7 -mtune=cortex-r7 -mthumb -fPIC -nostdlib -flto -static test.o start.o test_main.o -o test.gcc
I have tried specifying the linker plugin directly but then I get a different error:
arm-none-eabi-ld --static -fPIC --shared --fatal-warning --plugin <path_to_correct>/liblto_plugin.so test.o start.o test_main.o -test
arm-none-eabi-ld: <path_to_correct>.../lto-plugin.c:741: all_symbols_read_handler: Assertion 'lto_wrapper_argv' failed.
Aborted (core dumped)
What flags, parameters, etc. am I missing in my ld call?
I decided to learn how to make own OS by tutorial, I wrote boot on NASM and kernel on C also linker.ld and makefile. When I try linking all together I have this kind of error:
ld: library not found for -lgcc
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Also, I have installed binutils using homebrew but it doesn't help me. I have Mac OS 10.14
And this is my makefile:
CC = gcc
main: kernel.c linker.ld boot.asm
nasm -felf32 boot.asm -o boot.o
$(CC) -c kernel.c -o kernel.o -std=gnu99 -ffreestanding -Wall -Wextra
$(CC) -T linker.ld -o basilica.bin -ffreestanding -nostdlib boot.o kernel.o -lgcc
cp basilica.bin isodir/boot/basilica.bin
grub-mkrescue -o basilica.iso isodir
clean:
rm ./*.o ./*.bin ./*.iso ./isodir/boot/*.bin
What am I doing wrong? How can I fix this error: ld: library not found for -lgcc? Please help me.
I was really struggled with this error when I try to build a shared library. My code utilize the Lapacke library and also CUDA. when I compile them, there are no errors(I compile them as)
gcc -m64 -Wall -fPIC -c xxx.c -o xxx.o $(INC)
where INC includes all directories
INC=-I. -I${JAVA_HOME}/include/ -I${JAVA_HOME}/include/linux/ I$/home/sniu/lapack-3.5.0/lapacke/include/ -I${CUDA_INSTALL_PATH}/include/ -I/home/sniu/CBLAS/include/
for cuda part, I wrote it as:
nvcc -m64 -arch=sm_20 -Xcompiler -fPIC $(INC) -c xxx.cu -o xxx.o
but I got the error message at the link stage:
gcc -m64 -D_REENTRANT -Wall -fPIC -g -shared -o libjniWrapper.so jniWrapper.o cholesky_inv.o wls_acc.o utils.o -L/home/sniu/lapack-3.5.0 -L/opt/cuda-toolkit/5.5.22/lib64 -lm -llapacke -llapack -lblas -lgfortran -lrt -lcudart -lcublas -ldl
/usr/bin/ld: /home/sniu/lapack-3.5.0/liblapacke.a(lapacke_dpotrf.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/home/sniu/lapack-3.5.0/liblapacke.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
I am very sure libraries are there, I really confused why I got this error.
Any suggestions are appreciated, Thank you so much!
I have problem link libgcc into a static linked .so
it only happens when linking 64bit module with -m64
Ubuntu 64bit 12.10 gcc 4.7
also failed on Ubuntu 64bit 12.04 gcc 4.6
32bit no problem
$gcc -fPIC -c -o hello.o hello.c -m32
$gcc -shared -m32 hello.o -o libhello.so -static-libgcc -Wl,-Bstatic -lc
$ ldd libhello.so
statically linked
64bit failed
$ make
gcc -fPIC -c -o hello.o hello.c
gcc -shared -m64 hello.o -o libhello.so -static-libgcc -Wl,-Bstatic -lc
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libc.a(iofclose.o): relocation R_X86_64_32 against `__gcc_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libc.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libhello.so] Error 1
hello.c
#include <stdio.h>
int f(){
FILE *out = fopen("/tmp/x.log", "wb");
fclose(out);
return 1;
}
Makefile
all: libhello.so
libhello.so: hello.o
gcc -shared -m64 hello.o -o libhello.so -static-libgcc -Wl,-Bstatic -lc
hello.o: hello.c
gcc -fPIC -c -o hello.o hello.c
clean:
rm -f hello.o libhello.so
The answer is basically "you can't do that." You're trying to link non-PIC code into a shared library, which is simply impossible on the x86_64 (amd64) architecture. You would need a static but PIC version of libgcc, and I suspect that would be only the start of your problems.
One of the reasons why libgcc is normally shared is that a given running executable has to have one and only one copy of some of the key data structures that libgcc maintains. Static linking makes sense for a final executable, since that one and only one copy will be the one statically linked into the executable, but the whole point of a dynamic object is to be loaded into another executable (which in turn will have its own copy of libgcc, either shared or static).