I am compiling some files on the odroidC2 board (armv8-64bit) running Ubuntu 16.04.1, and I got the following error:
odroid#odroid64:~/flext-master/tutorial/simple1$ g++ -fPIC -L/usr/lib -pthread -shared -Wl,-S -L/usr/local/src/pd/bin -L/usr/local/lib -o pd-linux/release-single/simple1.pd_linux pd-linux/release-single/main.opp -lflext-pd_s
/usr/bin/ld: /usr/local/lib/libflext-pd_s.a(libflext_pd_s_la-flxlet.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `__stack_chk_guard##GLIBC_2.17' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libflext-pd_s.a(libflext_pd_s_la-flxlet.o)(.text+0x344): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `__stack_chk_guard##GLIBC_2.17'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
As you can see the -fPIC option is present. So I don't understand why the compiler suggest to "recompile with -fPIC". Any Idea?
The problem is not in the pd-linux/release-single/main.opp (BTW, maybe .cpp?) that you're compiling with -fPIC, but in the libflext-pd_s.a archive that contains an object libflext_pd_s_la-flxlet.o which is not compiled with -fPIC, so you need to recompile flext library properly.
Related
I am using these library in my project
Crow Framework
SQLPP11
SQLPP-Connector-MySQL
Howard Hinnant's Date
json11
and compiling my project using
g++ -std=c++1y -I ../../date main.cpp -lpthread -lsqlpp-mysql -lmysqlclient -lboost_system -ljson11
And everyday was running completely fine till yesterday. But now i am getting
this error,
┌─[shravan40#Debian] - [~/Work/algorithm] - [Fri Nov 18, 18:33]
└─[$] <git:(riskProfiling*)> g++ -std=c++1y -I ../../date main.cpp -lpthread -lsqlpp-mysql -lmysqlclient -lboost_system -ljson11
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(connection.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(prepared_statement.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(char_result.cpp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(bind_result.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(connection_handle.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
┌─[shravan40#Debian] - [~/Work/algorithm] - [Fri Nov 18, 18:53]
└─[$] <git:(riskProfiling*)>
Finally, i have figured out the solution.
It was the problem with g++ version. Recent versions g++-5 and g++-6 have such problems, But when i get back to old g++ version 4.9.2 everything is running smooth.
I had a similar issue after upgrading from 16.04 LTS to 18.04 LTS; but for me it was easily solved by running "make clean" and rebuilding the project. This might not work for everyone, but it is so simple that it seems likely that it is worth a try as a first resort for anyone who has this problem.
I had the same problem after upgrading from 16.04 LTS to 18.04 LTS with gtest/gmock library. Solution is you need recompile your libraries which you use in project with currently compiler.
I'm trying to compile a shared library (windows equivalent of a .dll) and it gives me the following error:
usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o: error adding symbols: Bad value
I've never seen this error before. Ever. I'm using codeblocks and g++ 4.8.1. What causes this error?
I'm compiling my own code using:
g++ -shared obj/Debug/src/Bitmap.o obj/Debug/src/Exports.o obj/Debug/src/Hooks.o obj/Debug/src/main.o obj/Debug/src/Platform.o obj/Debug/src/SharedMemory.o obj/Debug/src/SmartJNI.o -o bin/Debug/libGLXColour.so -libGL.so -pthread
/usr/bin/ld: obj/Debug/src/Bitmap.o
I'm Trying to Link a static Library to a shared library , I'm Getting the Following error
/usr/bin/ld: ../../../libraries/log4cplus/liblog4cplus.a(fileappender.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
../../../libraries/log4cplus/liblog4cplus.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
But this worked on a 32bit machine without any such error. I tried adding The -fPIC flags manually to the Makefile that too didn't solve the problem
I tried the -whole-archive flag as suggested here but with no success.
/usr/bin/ld: ../../../libraries/log4cplus/liblog4cplus.a(appenderattachableimpl.o): relocation R_X86_64_32S against `vtable for log4cplus::spi::AppenderAttachable' can not be used when making a shared object; recompile with -fPIC
../../../libraries/log4cplus/liblog4cplus.a(appenderattachableimpl.o): could not read symbols: Bad value
collect2: ld returned 1 exit status
Creation of liblog4cplus.a:
unzip log4cplus-1.1.0.zip
./configure --enable-static=yes --enable-threads=yes
vi Makefile and added -fPIC to CXXFLAGS and CFLAGS
make
Then for Compiling my shared library:
g++ -frtti -w -c -fPIC -I"Include_Directory" myfile.cpp
g++ -shared -fPIC -frtti -I"Include_Directory" -o mysofile.so myfile.o -Wl,--whole-archive "../../../libraries/log4cplus/liblog4cplus.a" -Wl,--no-whole-archive -ldl
Assuming you are generating a shared library, most probably what happens is that the variant of liblog4cplus.a you are using wasn't compiled with -fPIC. In linux, you can confirm this by extracting the object files from the static library and checking their relocations:
ar -x liblog4cplus.a
readelf --relocs fileappender.o | egrep '(GOT|PLT|JU?MP_SLOT)'
If the output is empty, then the static library is not position-independent and cannot be used to generate a shared object.
Since the static library contains object code which was already compiled, providing the -fPIC flag won't help.
You need to get ahold of a version of liblog4cplus.a compiled with -fPIC and use that one instead.
Add -fPIC at the end of CMAKE_CXX_FLAGS and CMAKE_C_FLAG
Example:
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall --std=c++11 -O3 -fPIC" )
set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -fPIC" )
This solved my issue.
Relocation R_X86_64_PC32 against undefined symbol , usually happens when LDFLAGS are set with hardening and CFLAGS not .
Maybe just user error:
If you are using -specs=/usr/lib/rpm/redhat/redhat-hardened-ld at link time,
you also need to use -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 at compile time, and as you are compiling and linking at the same time, you need either both, or drop the -specs=/usr/lib/rpm/redhat/redhat-hardened-ld .
Common fixes :
https://bugzilla.redhat.com/show_bug.cgi?id=1304277#c3
https://github.com/rpmfusion/lxdream/blob/master/lxdream-0.9.1-implicit.patch
I've got a similar error when installing FCL that needs CCD lib(libccd) like this:
/usr/bin/ld: /usr/local/lib/libccd.a(ccd.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
I find that there is two different files named "libccd.a" :
/usr/local/lib/libccd.a
/usr/local/lib/x86_64-linux-gnu/libccd.a
I solved the problem by removing the first file.
I also had similar problems when trying to link static compiled fontconfig and expat into a linux shared object:
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: /3rdparty/fontconfig/lib/linux-x86_64/libfontconfig.a(fccfg.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: /3rdparty/expat/lib/linux-x86_64/libexpat.a(xmlparse.o): relocation R_X86_64_PC32 against symbol `stderr##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
[...]
This contrary to the fact that I was already passing -fPIC flags though CFLAGS variable, and other compilers/linkers variants (clang/lld) were perfectly working with the same build configuration. It ended up that these dependencies control position-independent code settings through despicable autoconf scripts and need --with-pic switch during build configuration on linux gcc/ld combination, and its lack probably overrides same the setting in CFLAGS. Pass the switch to configure script and the dependencies will be correctly compiled with -fPIC.
I have a trivial piece of C++ code that looks something like this:
#include <boost/timer/timer.hpp>
int main(void) {
boost::timer::auto_cpu_timer t;
return 0;
}
I tried to compile and link it (with gcc 4.8.1 and GNU ld 2.23.52.20130828) as follows:
$ g++ -o test test.cc -lboost_timer
/usr/bin/ld: /tmp/cc2jP1jv.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv'
/usr/lib/libboost_system.so.1.54.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
One solution is to explicitly mention -lboost_system on the command line, and that works. However, I can also do:
$ g++ -Wl,--copy-dt-needed-entries -o test test.cc -lboost_timer
According to the ld documentation "with --copy-dt-needed-entries dynamic libraries mentioned on the command line will be recursively searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary", so this all makes sense: ld is figuring out from boost_timer that it also needs to link against boost_system in order to resolve all the symbols.
However, I realised that this also works:
$ g++ -fPIC -shared -o test test.cc -lboost_timer
Obviously, I've now generated a shared object rather than an executable. Apparently, though, ld was able to figure out that it needed to link the shared object against boost_system:
$ ldd test | grep boost_system
libboost_system.so.1.54.0 => /usr/lib/libboost_system.so.1.54.0 (0x00007f385246e000)
So my question is this: why is symbol resolution different when building a shared object versus an executable? How is ld able to figure out that my shared object should be linked against boost_system without my specifying --copy-dt-needed-entries?
The direct answer to my question is in the --[no-]allow-shlib-undefined option to ld, I think. From the man page:
The default behaviour is to report errors for any undefined symbols
referenced in shared libraries if the linker is being used to create
an executable, but to allow them if the linker is being used to create
a shared library.
Therefore, when I build with -shared, the symbols in boost_system are undefined, but the default behaviour of ld is not to care. It can be told to care:
$ g++ -fPIC -shared -Wl,--no-allow-shlib-undefined -o test test.cc -lboost_timer
/usr/bin/ld: /tmp/cc6j1de3.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv'
/usr/lib/libboost_system.so.1.54.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Similarly, we can tell it not to care when building an executable:
$ g++ -Wl,--allow-shlib-undefined -o test test.cc -lboost_timer
/tmp/ccUHoCIU.o: In function `__static_initialization_and_destruction_0(int, int)':
test.cc:(.text+0x7a): undefined reference to `boost::system::generic_category()'
test.cc:(.text+0x86): undefined reference to `boost::system::generic_category()'
test.cc:(.text+0x92): undefined reference to `boost::system::system_category()'
collect2: error: ld returned 1 exit status
But creating the binary fails without being able to define those symbols.
Thanks #CharlesBailey for pointing me in the right direction!
There are differences in the collect2 command that may be relevant. The different commands are compared at http://imgur.com/eMr2tY2 . The right hand side creates the shared library (-fPic -shared), the left is the normal compile.
I get this error at the linker stage when compiling the webkit-1.1.5 package on my Ubuntu 9.04 box:
libtool: link: gcc -ansi -fno-strict-aliasing -O2 -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -fvisibility=hidden -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -O2 -o Programs/.libs/GtkLauncher WebKitTools/GtkLauncher/Programs_GtkLauncher-main.o -pthread ./.libs/libwebkit-1.0.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libcairo.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so -lfontconfig /usr/lib/libgmodule-2.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -pthread
make[1]: Leaving directory `/home/nagul/build_area/webkit-1.1.5'
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp: In function ‘NPError webkit_test_plugin_get_value(NPP_t*, NPPVariable, void*)’:
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp:221: warning: deprecated conversion from string constant to ‘char*’
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp:224: warning: deprecated conversion from string constant to ‘char*’
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp: In function ‘char* NP_GetMIMEDescription()’:
WebKitTools/DumpRenderTree/gtk/TestNetscapePlugin/TestNetscapePlugin.cpp:260: warning: deprecated conversion from string constant to ‘char*’
/usr/bin/ld: Programs/.libs/GtkLauncher: hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [Programs/GtkLauncher] Error 1
make: *** [all] Error 2
I'd like some pointers on how to attack this problem, either by looking into the "hidden sybmol" error or by helping me understand what the "Nonrepresentable section on output" message from the linker actually means.
I have already checked that this is consistent behaviour that persists across a make clean;make invocation.
I've received the "nonrepresentable section on output" error when crosscompiling for ARM and some of the libraries was not correctly compiled with -fPIC.
Pretty sure that's not the error here though...
My answer is specific to the combination of the hidden symbol (...) is referenced by DSO and Nonrepresentable section on output errors.
The short answer is: a symbol was marked extern but also marked hidden (see Visibility (GCC wiki) and How To Write Shared Libraries (Ulrich Drepper)). No objects or archives were linked in to satisfy the dependency, but a shared object was linked in with a matching symbol.
You probably compiled with -fvisibility=hidden, and whether it was a compiler-added feature (like stack protector) or something else entirely, the symbol emitted in your code overrode the default visibility of an undefined symbol reference of the same name in libc_nonshared.a that would normally be satisfied by libc.so.
You can reproduce a similar problem like this:
#include <stdio.h>
extern __attribute__((visibility ("hidden")))
FILE* open_memstream( char**, size_t* );
char* asdf;
size_t mysize;
FILE* blah() {
return open_memstream( &asdf, &mysize );
}
... then compiling it:
# with gcc 4.9.2:
~ gcc badcode.c -shared -fPIC -o libbad.so -lc
/tmp/ccC0uG80.o: In function `blah':
badcode.c:(.text+0x19): undefined reference to `open_memstream'
/usr/bin/ld: /tmp/libbad.so: hidden symbol `open_memstream' isn't defined
/usr/bin/ld: final link failed: Bad value
# with gcc 4.4.7:
~ gcc badcode.c -shared -fPIC -o libbad.so -lc
/tmp/cc2SHUFD.o: In function `blah':
badcode.c:(.text+0x26): undefined reference to `open_memstream'
/usr/bin/ld: /tmp/libbad.so: hidden symbol `open_memstream' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
# with oracle solaris studio (still in Linux) 12.3:
~ cc -shared -Kpic -o /tmp/libbad.so badcode.c -lc
badcode.o: In function `blah':
badcode.c:(.text+0x32): undefined reference to `open_memstream'
/usr/bin/ld: /tmp/libbad.so: hidden symbol `open_memstream' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
In short: I've forward declared the existence of a symbol, marked it hidden, then didn't link in a static library or object file that satisfied the dependency. Since it's marked hidden, the dependency must be satisfied, otherwise it's an invalid ELF object.
In my specific case, a header was going down the wrong #if path and causing the above hidden declaration of open_memstream.
Please try removing the -fvisibility=hidden option from the commandline. It will produce a larger object (with some unnecessary symbols, which won't matter in the end because it is an execultable), but should eliminate the problem. This is not a solution; rather a workaround. Please check (this is just a hunch) if there are no libc version mismatches between libraries and GtkLauncher.o