shared-libraries

问题 I'd like to know if it is possible (and if yes: how) to cross compile shared libraries with Go. Say I have this code: package main import "C" //export DoubleIt func DoubleIt(x int) int { return x * 2 } func main() {} in src/doubler/main.go . On Mac I can run go build -o libdoubler.dylib -buildmode=c-shared doubler to get a shared library called libdoubler.dylib . Similar on linux, just with the extension .so . Now I'd like to use Linux as the main platform to build my libraries (for Mac and

问题 I want to write a shared library in such a way that it is possible to isolate it’s memory usage from the application it is linked against. That is, if the shared library, let’s call it libmemory.so , calls malloc , I want to maintain that memory in a separate heap from the heap that is used to service calls to malloc made in the application. This question isn't about writing memory allocators, it more about linking and loading the library and application together. So far I’ve been

问题 I experience the collapse of definitions i can't make sense of. Schematically the problem is as follows: The main project file has two includes: include <lib1.h> include <lib2.h> The first header includes couple of other headers from the library, in one of those there is a direct (not covered with a name-space) definition: template<typename T> class SparseMatrix; The lib2.h has the following inside namespace lib2 { using namespace lib3; class ... { ... SparseMatrix<double> ... ... } } Inside

问题 If I use dlopen on the same lib/file two times in the same application-run, will it yield the same handle in both cases? Is there any guarantee for this (a short experiment showed that it at least does on my box)? I'm currently playing around with a little plugin-system (out of curiosity) and if there would be some kind of guarantee for this observed behaviour I could use this address as a key for a plugin to prevent duplicated loads. 回答1: Yes. The dlopen(3) linux man page says: If the same

问题 I have started developing a very simple Android application that consists of three parts: the Java application itself a pre-built shared library (we'll call it libfoo ) another shared library that uses the pre-built library (we'll call it libfoowrapper ) The file system looks something like this: jni Android.mk libfoo.so foowrapper.c The Android.mk file contains the following contents: LOCAL_PATH := $(call my-dir) #============================== include $(CLEAR_VARS) LOCAL_MODULE := foo

问题 I have a project that produces a shared library which is linked against another, also shared, library. When I compile and link it with gcc 4.4, everything works: no compile-time warning or error, no linking time warning or error and ldd libmyproject.so correctly reports the dependency with the other shared library. When I compile and link it with gcc 4.5, on the other hand (with the exact same flags), I have the following symptoms: no compile-time warning or error, no linking time warning or

问题 I’ve created simplest EXECUTABLE and SHARED_LIBRARY. SHARED_LIBRARY doesn’t get loaded without changing LD_LIBRARY_PATH: # ./hello ./hello link_image[1995]: failed to link ./hello CANNOT LINK EXECUTABLE # LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./hello Hello, world! All code below: first.h #ifndef FIRST_H #define FIRST_H extern int first(int x, int y); #endif /* FIRST_H */ first.c #include "first.h" int first( int x, int y ) { return x + y; } hello.c #include <stdio.h> #include "first.h" int main(

问题 I recently installed the hdf5 library on an ubuntu machine, and am now having trouble linking to the exported functions. I wrote a simple test script readHDF.cpp to explain the issue: #include <hdf5.h> int main(int argc, char * argv[]) { hid_t h5_file_id = H5Fopen(argv[1], H5F_ACC_RDWR, H5P_DEFAULT); return 0; } The compile command is g++ -Wl,-rpath,$HOME/hdf5/lib -I$HOME/hdf5/include \ -L$HOME/hdf5/lib -l:$HOME/hdf5/lib/libhdf5.so readHDF.cpp which returns the following error /tmp/cc6DXdxV.o

问题 How can I tell if a certain c++ library was linked using c++11 standard? 回答1: An elf binary would by default contain the signature of compiler version used. Now, with regards to compiler flags used, If -frecord-gcc-switches is used at compile time, then, you can find the signature in ELF executable. g++ -frecord-gcc-switches -std=c++0x trial.cpp readelf -p .GCC.command.line a.out String dump of section '.GCC.command.line': [ 0] -imultilib . [ d] -imultiarch x86_64-linux-gnu [ 2a] -D_GNU

问题 I have the following problem. I write a shared library #include <stdio.h> #include <stdlib.h> static void __attribute__ ((constructor)) test_init(void); static void __attribute__ ((destructor)) test_clean(void); /* Initialization */ static void test_init(void){ fprintf(stderr,"initialized\n"); fflush(stderr); } /* CleanUp */ static void test_clean(void){ fprintf(stderr,"cleaned up\n"); fflush(stderr); } double test (double x){ return 2.0*x; } And compile it using gcc -c -fPIC testlib.c -o