I am trying to build an executable which should be linked with the
mosquitto (libmosquitto.a)
json-c (libjson-c.a)
Also, there is a custom C API built as a static library as well: myCAPI.a
My linux is Ubuntu 18.04 running under virtual machine. Also, I am using cmake tool.
So, when I'm trying to build an executable I am getting the following linking errors:
myCAPI.a(some_client.c.o): relocation R_X86_64_32S against symbol 'valueTypes' can not be used when making a PIE object; recompile with -fPIC
libmosquitto.a(connect.c.o): relocation R_X86_64_32 against '.rodata' can not be used when making a PIE object; recompile with -fPIC
// etc.
libjson-c.a(strerror_override.c.o): relocation R_X86_64_32S against '.data' can not be used when making a PIE object; recompile with -fPIC
// etc.
I have a googled a lot and find some articles where it is said that the issue is connected to gcc's version (either PIE or PIC is selected as an option). So, I tried to build my environment as follows:
cmake -no-pie ../
Also in this way as well:
cmake -fPIC ../
Here is my CMakelists.txt
cmake_minimum_required(VERSION 3.10)
set(EXAMPLE_NAME "PublishValues")
project(${EXAMPLE_NAME})
file(GLOB SOURCES "src/*.c")
include_directories(include ../../include )
set(PROJECT_LINK_LIBS libtvcmiclient.a libmosquitto.a libcares.a libjson-c.a libssl.a libcrypto.a libpthread.so libdl.so)
link_directories(../../3rdparties ../../libs)
add_executable(${EXAMPLE_NAME} ${SOURCES})
target_link_libraries(${EXAMPLE_NAME} ${PROJECT_LINK_LIBS})
Unfortunately, the linking errors still there.
Related
I recently added libcurl dependency to my c++ library. I statically compiled libcurl with-nss for https support. I use Debian 7 for compilation.
I create two builds for my library - static and shared
Shared version is linking fine with binaries built on any Linux distro, but the static build only links with binaries when compiled on Debian 7.
I tried static linking on Ubuntu 16.04, Debian Stretch but all are reporting following error during compilation:
g++ -Wall -o Sample Sample.cpp -Wl,-Bstatic -L. -lMyLibrary -Wl,-Bdynamic -lssl3
/usr/bin/ld: ./libMyLibrary.a(libcurl_la-nss.o): undefined reference to symbol 'CERT_GetDefaultCertDB##NSS_3.2'
//usr/lib/x86_64-linux-gnu/libnss3.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:22: recipe for target 'Sample' failed
make: *** [Sample] Error 1
Static compilation now only works on Debian 7 which is a big problem.
Static libraries are just archives of object files. As one consequences, they don't carry any dependency information. So, if you link a static library which depends on some other libraries, you have to add these explicitly in your linking command.
In your case, this means:
find whoever defines CERT_GetDefaultCertDB##NSS_3.2 -- some answers to this FAQ could help here
add this library to your linker command (with -l, after your static library)
I am trying to create .so dynamic library from *.o files and facing below issue.
LOG:
[nptemp-static]$ gcc -shared *.o -o libexample.so
/usr/bin/ld: bindings_hubbub_parser.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
bindings_hubbub_parser.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
Any idea? Do I need to recompile my whole source code with the option specified?
Actually, I am not aware of the source code which I compiled because all the source code is open source which I downloaded and compiled by following instructions in README.
I am trying to create .so dynamic library from *.o files and facing below issue.
This is not that simple. In practice, you should compile specifically when making a shared library, at least on Linux.
(Perhaps you might need to edit your Makefile or configure somehow your build automation if it was not designed for building a shared library; if building some free software library, you might ask help from its authors or community)
Shared libraries want to have position independent code. So you need to compile their source code with the -fPIC flag passed to g++ or gcc (see this). You could also want to explicit the rpath.
Read Drepper's paper: How To Write Shared Libraries.
I wanted to use INCR in redis beyond its maximum value 9,223,372,036,854,775,807. So I write a redis module C code using gmp.h. In C code I read the value in the key (the key to be incremented) and incremented by using functions in gmp.h and then written back to the same key.
I create .o files and then .so files and it works fine in my mac. When I gave the .so file to my friend, the .so file did not load and an error came for her.
Library not loaded: /usr/local/lib/libgmp.10.dylib
I guess this happend because my friend not installed gmp in her mac
But I thought it will work. Is there any way to make it work in my friend's macbook without installing the library ?
Commands used to created .o and .so files
gcc -dynamic -fno-common -std=gnu99 -c -o mycommand.o mycommand.c
ld -o mycommand.so mycommand.o -bundle -undefined dynamic_lookup -lc -lgmp
I'm trying to make an "C" application for my NXP(Freescale) imx6 that Debian OS installed on it. My host machine is Ubuntu 16.04. I'm using eclipse as an IDE and I can manage to cross compile until today. I use arm-linux-gnueabihf-gcc as an compiler and arm-linux-gnueabihf-ld as an linker. I added -lasound option to my linker parameter, but still can not build the application. I get an error
arm-linux-gnueabihf-ld: cannot find -lasound
I think I don't have the libasound.so file on my Ubuntu (Host) machine and my linker couldn't link to library to my application.
I copied the libasound.so file from my ARM machine to my host machine to the /home/user/Downloads folder, but still couldn't compile.
Is there a step to use ALSA library in Cross Compilation project before build?
Here is the output of build operation
Building target: tihc_linux_application
Invoking: GCC C Linker
/usr/bin/arm-linux-gnueabihf-ld -static -L/home/user/Downloads -pthread -lasound -o "main" ./src/main.o
/usr/bin/arm-linux-gnueabihf-ld: mode armelf_linux_eabi
/usr/bin/arm-linux-gnueabihf-ld: cannot find -lasound
You ask for static link (via -static) but provide shared library so ld probably ignores it (to be sure you can run with -Wl,--verbose). One option is to cross-compile libalsa from scratch and then use resulting static lib to link your app. Another option is to search for pre-compiled gnueabihf libalsa somewhere...
I'm trying to link some 3rd party static libraries into a dynamic library. However I get the error -
relocation R_X86_64_32 against `TMC_END' can not be used when
making a shared object; recompile with -fPIC
On Solaris, you can tell GCC/ G++ to allow linking with code that wasn't compiled with -fPIC, through the option -mimpure-text. (Found via great answer here) However this option isn't recognized on Ubuntu (16.04, g++ version 5.4.0):
g++: error: unrecognized command line option ‘-mimpure-text’
Is there any equivalent option, or any other solution except for compiling the 3rd parties static libraries with -fPIC enabled?
Thanks!
P.S Excellent explanation on relocations here