When compiling a qbs project in QtCreator, I get a lot of these errors:
...requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
So, like suggested here How to recompile with -fPIC I want to add --enable-shared to ./configure options.
Please tell me where in QtCreator UI I have to put that.
Related
I am working on a project which eventually requires me to link my code against my customized version of libc, libstdc++ and libgcc. Now I am learning what libraries are linked by default.
I tried to compile my project code with -nolibc and manually provide the needed libraries in the argument list.
g++ -fuse-ld=gold -O2 -o main -static -nolibc main.cpp -lgcc -lm -lc
I got the following error, showing that I missed some libraries.
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_eh.a(unwind-dw2-fde-dip.o):function _Unwind_Find_FDE: error: undefined reference to 'dl_iterate_phdr'
Which library is missing here?
I'm doing all this on a VLE and below is what I'm working with:
Running OS: Linux Centos 7
GCC:4.8.5 & 7.1.0
I'm trying to use GNU autotools (libtool, autoconf, automake) to build a project in 32-bit using gcc-7.1.0. Also, as a requirement, I must do this on Centos 7 and use gcc-7.1.0.
Apparently, the latest version of gcc that can be officially upgraded through yum is 4.8.5. However, I successfully installed gcc-7.1.0 from the official source and even included --enable-multiarch --with-list-multilib=m32,m64 --enable-multilib during configure.
The issue I'm running into is that the autotools seem to want to use the 64-bit libraries even though I'm including -m32 compiler switch in CXXFLAGS, CFLAGS, and LDFLAGS. The reason I think it's using 64-bit libraries at linking is that I get the error below:
libtool: link: g++ -m32 -fPIC -Wall -Wextra -Weffc++ -Werror -std=c++03 -O2 -o fldprog fldprog-icpprog.o ../../ ../seal3/fld/src/.libs/libbsp_fld.a -lpci /usr/local/lib/../lib64/libstdc++.so -lm -Wl,-rpath -Wl,/usr/local/lib /../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64
/usr/local/lib/../lib64/libstdc++.so: error adding symbols: File in wrong format
And when I rename /usr/local/lib64 to lib64_something, the program will compile without any errors. However, I want to find a permanent solution.
I've searched the internet for answers but none of them seem to really work. I've tried including -L/usr/local/lib to AM_LDFLAGS, AM_CFLAGS in configure.ac
I'd appreciate any input. Thank you.
Edit:Revised
I am trying to build libass into a shared library with static linking under MinGW-w64. When I configure with
./configure --disable-static --enable-shared
it generates the shared library (dynamically-linked) as expected. However, when I attempt to force static linking by setting
LDFLAGS=-static
instead of generating a statically-linked shared library (.dll with no dependency), it generates a static library (.a).
I am almost certain that I have all the dependent static libraries and no error or warning message is shown in the make process.
Can anyone please shed some light on what I'm doing wrong?
libtool says No.
The package's stock autotools ltmain.sh script parses the linkage flags and
if it finds -static it will not build a shared library, just a static
one.
Which is the most it could reasonably do, because you can't statically link a shared
library. A shared library must consist entirely of Position Independent (PIC)
code or the linkage will fail, whereas a static linkage will call for the linkage
of non-PIC object files, contributed by the non-PIC standard and runtime libraries,
if nothing else.
foo.c
#include <stdio.h>
void foo(void)
{
puts("foo");
}
Build a dynamically linked shared library:
$ gcc -c -fPIC foo.c
$ gcc -shared -o libfoo.so foo.o
$ file libfoo.so
libfoo.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), \
dynamically linked, BuildID[sha1]=1adff7204d84d138a80bc4b6f3f38211e4b42812, \
not stripped
Attempt to build a statically linked shared library:
$ gcc -c -fPIC foo.c
$ gcc -shared -static -o libfoo.so foo.o
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/crtbeginT.o: \
relocation R_X86_64_32 against hidden symbol `__TMC_END__' cannot be used \
when making a shared object
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
The static lib is just an ar package.
You can use command of ar to make the pack and unpack it.
In GCC, if I compile something into a shared library with GCC with g++ -shared func.cpp -o libfunc.so -fPIC, internal function calls to global symbols go through GOT in this generated shared library file. But if I compile with g++ func.cpp -o libfunc.so -mcmodel=large, it will not generate GOT but instead relocate by patching with R_X86_64_64 style relocation directly.
I want this behavior for executables as well. If I compile an executable with g++ main.cpp libfunc.so -o a.out, GCC will generate GOT for any function call from main.cpp to one defined in libfunc.so. I don't want this behavior. I want R_X86_64_64 style relocation. How can I achieve that?
Executables are compiled with -fPIE by default in modern distros for security reasons. To get old behavior add -no-pie to CFLAGS/CXXFLAGS.
using gcc 4.5.1 in a 64bit x86 machine,I first create a.o as following:
g++ -fPIC -c a.cc -o a.o
then try to create liba.so as following:
g++ -static-libstdc++ -shared -W1,-soname,liba.so -o liba.so.1.0.0 a.o
but failed, with the following information:
relocation R_X86_64_32S against `vtable for __gnu_cxx::stdio_filebuf >' can not be used when making a shared object; recompile with -fPIC
I try to recompile libstdc++ library,with -fPIC added,but it failed anyway
I would expect that the static libstdc++ library was not build with -fPIC, and therefore can't be linked into a shared library.
Theoretically you could put non-PIC compiled code into a dynamic library, but it wouldn't be sharable (each program using it would have to have its own copy) so it's often not implemented.
You're going to need to link against the shared C++ library, make your own library a static library, or else rebuild libstdc++ yourself and grab the .o files from the build directory.
There is a similar question about this topic on stackoverflow, which refers to an external site about static linking of libstdc++.