I am trying to use POCO libraries for threading framework in my project. I am getting linker errors for POCO functions like
ServiceMain.o: In function _GLOBAL__sub_I__ZN18CServiceMain10mpInstanceE':
ServiceMain.cpp:62: undefined reference toPoco::Event::Event(Poco::Event::EventType)'
Logging.o: In function _GLOBAL__sub_I__ZN7Log11mLogStringsB5cxx11E':
Logging.cpp:88: undefined reference toPoco::Mutex::Mutex(Poco::Mutex::MutexType)'
Could some one tell me what is the issue ? And what is the meaning of "_GLOBAL__sub_I" ?
Your issue looks like you've failed to correctly include either the linker or include path flags for Poco's Foundation library. If you're on a *nix system your flags will look something like this:
-L/path/to/poco/libs/ -lPocoFoundation -I/path/to/poco/include
On OSX with brew installed Poco I would use:
-L/usr/local/lib -lPocoFoundation -I/usr/local/include
Related
I have this error message while building the curl library:
libssl.a(s2_clnt.o): relocation R_X86_64_32 against `.rodata' can not
be used when making a shared object; recompile with -fPIC
I tried to use the -fPIC switch - nothing helps. The openssl library was before compiled without any error. make check passed as well.
Info: I am compiling curl against another version of glibc - the include path is provided in ./configure with the $CPPFLAGS and $LDFLAGS == -L/usr/glibc-2.22/lib [== this is the path to the new glibc version]
This error is thrown only when I compile it with the new glibc version.
You get this kind of error when one object is built with hidden symbols and another one isn't.
Since I see you're trying to link a .a archive file aka static library, I assume that static library was built with different hidden symbol options than what you're using with curl.
I think that you can also get this when one object is using PIC and the other one isn't. To fix that compile the static library and curl with the same PIC settings.
Here is the solution for the issue collection I had in the past days:
several make issues...
I was trying to cross compile a file for ARM architecture using arm-lunux-gnueabi cross compiling tool chain. But I am getting below error : -
undefined reference to `clock_gettime'
Please guide me which header files or libraries should I include and how , to get rid over this error.
I am using following command for cross compiling : -
make ARCH=arm CROSS_COMPILE -C /path/to/source
Help is appreciated.
As the documentation says:
Note
Most systems require the program be linked with the librt library to
use these functions.
So link to the rt library with the -lrt flag.
I have a shared library which is supposed to export only one function which is marked with __attribute__ ((visibility ("default"))). It also links with another static library (fftw), and
#include<fftw3.h>
is preceded with:
#pragma GCC visibility push(hidden)
The linker command used:
g++.exe -fvisibility=hidden -shared -o mylib.dll -Wl,--out-implib,mylib.dll.a -Wl,--no-whole-archive libfftw3.a libfftw3_omp.a -lgomp
Now the resulting library is huge and if I check the exported functions it includes ALL fftw functions, and ALL function from my files. It looks like mingw ignores visibility options. I read that previously it gave warning about -fvisibility, but now it compiles with no warnings whatsoever.
Does mingw and gcc 4.6.1 support visibility flags? If yes, how do I get rid of all unnecessary stuff in my shared library?
Mingw is a Windows port of GCC toolchain but Windows dll are not Linux so. Especially the link part is different. To specify the visibility with MingGW you have to go the Windows way and annotate your classes and functions with :
__declspec(dllexport) while compiling the library
__declspec(dllimport) while linking
If you want multiplatform support for the GCC toolchain you can add a header in your project doing that for you. For a step by step example and lots of details have a look at GCC's visibility guide.
Windows PE object files do not have visibility attributes. The closest is dllexport/dllimport, but that's only for shared libraries (DLL's). So either you don't mark all FFTW functions with __declspec(dllexport), and hope linking the static library does The Right Thing (tm), or you take care not to link to FFTW if linking with your library.
It should warn about bad visibility attributes, perhaps you need to turn up the warning level -Wall -Wextra -pedantic).
I want to use CUDPP library in my project. I've downloaded sources from project page. Unfortunatly, when I ran "make", there was only static library build. I've looked into Makefile files and haven't found any dynamic lib configuration. I don't want to keep static library with the project - it's totally non-portable way.
My question is: how can I build .so dynamic library of CUDPP, without writing my own Makefile/compiling it manually? Maybe someone already did it?
EDIT: I've replaced "g++" with "g++ -fPIC", "gcc" with "gcc -fPIC" and "nvcc" with "nvcc -Xcompiler -fpic". When I unpack obj files from archive, and link them to shared lib, I've got no error. However, my application crashes at start, when linked with this library.
when you compile pass the flag -Xcompiler -fpic to nvcc. If you link against any cuda libraries make sure you've linked to the shared libs, otherwise you can't link it. Hopefully that's all you need.
Are you also using -shared to create the library? You shouldn't need to extract anything from an archive if it is working correctly.
If you run ldd on your executable it will show you what dynamic linking is required by the app and you can check that the -fPIC etc. worked correctly. Also make sure that the .so library is on your LD_LIBRARY_PATH (sorry if that's obvious, no harm in checking).
I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install