dynamic-linking

GCC -rdynamic not working with static libraries

冷暖自知 提交于 2019-11-30 07:39:23
问题 Why is -rdynamic not exporting the symbols in .a files but is exporting the symbols in .o files ? I have an app and a plug-in in a .so file. The main app is linked using a series of object files and one static library, like this: CXXFLAGS = $(CXXFLAGS_COMMON) -rdynamic STATICLIBS = ../Utilities/Utilities.a ... all: $(CXX) $(CXXFLAGS) -o $(SAMPLE) main.o $(STATICLIBS) $(SHAREDLIBS) $(INCLUDES) (CXX is g++ 4.5.2 on Ubunut, I use mainly -std=c++Ox for compilation) In this case, the symbols in

Dynamic loading and weak symbol resolution

谁说我不能喝 提交于 2019-11-30 07:07:13
问题 Analyzing this question I found out some things about behavior of weak symbol resolution in the context of dynamic loading ( dlopen ) on Linux. Now I'm looking for the specifications governing this. Let's take an example. Suppose there is a program a which dynamically loads libraries b.so and c.so , in that order. If c.so depends on two other libraries foo.so (actually libgcc.so in that example) and bar.so (actually libpthread.so ), then usually symbols exported by bar.so can be used to

Android Static Linking vs Dynamic Linking against glibc

只谈情不闲聊 提交于 2019-11-30 02:51:01
问题 I have been cross-compiling some Linux tools (and some of my own C code) to Android and one of the challenges that I face is that Android's libc has some missing/stripped components and I end up patching my code to make it work with Android's libc (for e.g. a problem like this http://credentiality2.blogspot.com/2010/08/compile-ncurses-for-android.html) Q1 : How do I go about statically linking against glibc (and other dependencies) while cross-compiling with the arm toolchain (or ndk-build)?

Recommendation for C++ wrapper for cross platform in-process dynamic library bindings (i.e. a lightweight, high performance COM or CORBA) [closed]

泪湿孤枕 提交于 2019-11-30 02:24:32
We're developing an application that will have a plug-in "architecture" to allow consumers of the app to provide their own proprietary algorithms. (We will basically have a set of parsers and allow third parties to provide their own as well) The domain space requires very high performance, so out-of-process bindings are not going to work and we'd rather leave the heavyweight things like CORBA and COM alone. Basically we're looking for a simple cross-platform wrapper around: load library from a relative path provide a mapping of the particular dll/.so to some configuration/name do some

Linking error with `libopencv_highgui.so` under Ubuntu 14.04, strange result with `libtiff.so.5`

跟風遠走 提交于 2019-11-30 01:42:29
问题 Problem I'm compiling the deep learning library Caffe in Ubuntu 14.04(64 bit). OpenCV( Version: 2.4.8+dfsg1-2ubuntu1 ) is installed from ubuntu packages server with : sudo apt-get install libopencv-dev Compile Caffe with CMake 2.8. Linking error: Linking CXX executable caffe- /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4.8: undefined reference to `TIFFOpen@LIBTIFF_4.0' Infomation It seems some symbols of TIFF library were not found. I made some effort to find the reason(without luck).

How can LD_LIBRARY_PATH be changed within CMake?

六月ゝ 毕业季﹏ 提交于 2019-11-30 00:24:53
问题 I have a local shared library which is not in $LD_LIBRARY_PATH. I want to run my executable, but since it cannot find the shared library in the system folders, it outputs "error while loading shared libraries". A possible fix for this is to export a new LD_LIBRARY_PATH containing the local library folder. How can I export automatically this environment variable within CMake? 回答1: If your shared lib is not build in the same CMake project of your executable, you can use the CMake rpath handling

Clang linker issues (from source, to gcc-snapshot)

限于喜欢 提交于 2019-11-29 22:31:36
问题 I cannot seem to get this to work. I configured with the --with-gcc-toolchain= where after the equals I put the directory where gcc was ( /usr/lib/gcc-snapshot/bin ). I also looked into the answers to " clang linker problem" but I do not see how I can get the accepted answer to find the correct location, and the symlink answer would have worked, except that all of the directories that it is searching exist (copying the lib folder from gcc-snapshot to one of the include locations does not seem

Why is fPIC absolutely necessary on 64 and not on 32bit platforms?

£可爱£侵袭症+ 提交于 2019-11-29 21:07:41
I recently received a: ...relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC error while trying to compile a program as a shared library. Now the solution to this is not too difficult (recompile all dependencies with -fPIC), but after some research it turns out that this problem is only present on x86-64 platforms. On 32bit any position dependent code can still be relocated by the dynamic loader. The best answer I could find is: x86 has support for .text relocations (which is what happens when you have position-dependend code).

Why does gcc not implicitly supply the -fPIC flag when compiling static libraries on x86_64

核能气质少年 提交于 2019-11-29 19:05:00
I've had numerous problems compiling shared objects that link statically against static libraries. This problem only shows up on x84_64 platforms. When doing the same compilation work on x86_32 I do not have any problems. Perhaps this is a OS specific GCC configuration thing, but my research indicates that its how GCC works on x86_64 platforms. Anyhow, I am using gcc 4.4.3 on Ubuntu 10.04 x86_64. How is the problem fixed ?... Making sure all the static library dependencies are compiled with -fPIC. Question 1: What is the difference between -fpic and -fPIC (apparently -fPIC generates more

How to compile a cpp and then link it to a shared library

北战南征 提交于 2019-11-29 17:34:48
I want to have the functions which are defined in another .cpp file become available in another simulation tool. I found the following code in this question: -finstrument-functions doesn't work with dynamically loaded g++ shared objects (.so) Trace.cpp #include <stdio.h> #ifdef __cplusplus extern "C" { void __cyg_profile_func_enter(void *this_fn, void *call_site) __attribute__((no_instrument_function)); void __cyg_profile_func_exit(void *this_fn, void *call_site) __attribute__((no_instrument_function)); } #endif void __cyg_profile_func_enter(void* this_fn, void* call_site) { printf("entering