shared-libraries

This is a follow up of this question . As mentioned in the comments to the answer: An inline variable has the property that - It has the same address in every translation unit . [...] Usually you achieved that by defining the variable in a cpp file, but with the inline specifier you can just declare/define your variables in a header file and every translation unit using this inline variable uses exactly the same object. Moreover, from the answer itself: While the language does not guarantee (or even mention) what happens when you use this new feature across shared libraries boundaries, it does

All: I have successfully set up two projects (Hello and World) in one workspace (HelloWorld). These are simple projects that are supposed to work together as a main project and a shared library project. This is the structure: HelloWorld Hello src Hello.cpp Debug src Hello - [x86_64/le] World src World.cpp World.h Debug src libWorld.dylib - (x86_64/le] I have followed all instructions and finally was able to get them to compile with no errors. However, when I try to run the Hello project I receive the following error: dyld: Library not loaded: libWorld.dylib Referenced from: /Users/pdl

I've been trying to compile with std::atomic, and I'm getting unresolved references to __atomic_load, __atomic_store, and __atomic_store_16. I know in a later version of gcc (4.8+?) you include -latomic, but I'm compiling with gcc 4.7.3; I've tried adding -latomic_ops and -latomic_ops_gpl, but neither seem to do much. I am installing gcc 4.8.1 now, but I do have a release platform that'll really need to be compiled for 4.7.3. Many thanks. Edit: Ok, here's some code that results in the problem I have: atomics.cpp #include <atomic> #include <stdint.h> struct dataStruct { int a; uint16_t b; float

I created a shared library ( *.so ) using the *.o object code files (C source code) using RVDS compiler on Windows Host. I link this shared object with a application (using gcc for ARM target on Linux host) and obtain a executable, which on running generates segmentation fault. (I know I have to debug it!) Instead of creating shared library, if I create a static library with same source files, and then link with the application, and then execute the application it works fine as expected. So my questions are: Do I need to export symbols(functions exported to application) or any other symbols,

I'd like to run multiple Java processes on my web server, one for each web app. I'm using a web framework (Play) that has a lot of supporting classes and jar files, and the Java processes use a lot of memory. One Play process shows about 225MB of "resident private" memory. (I'm testing this on Mac OS X, with Java 1.7.0_05.) The app-specific code might only be a few MB. I know that typical Java web apps are jars added to one server process (Tomcat, etc), but it appears the standard way to run Play is as a standalone app/process. If these were C programs, most of that 200MB would be shared

I am building the google-gflags commandline flags library for C++ on Mac OS X (10.7.1). The build process is as such: $ ./configure --prefix=output $ make $ make install I'd like to change the install name of the generated shared library at build time and not use install_name_tool afterwards. By default, the install name of the generated shared library, libgflags.dylib , is the output path: $ otool -L ./output/libgflags.dylib $ ./output/libgflags.dylib: /tmp/gflags-1.5/output/lib/libgflags.0.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libstdc++.6.dylib (compatibility

I know that LD_LIBRARY_PATH is evil and it's a good habit to avoid using it. I have a program called server.c on a remote Solaris 9 server that holds two versions of openssl library (0.9.8 and 1.0.0) and I'm using gcc 3.4.6. My program need to link to 1.0.0a version. Because it's work environment, I don't have the right to modify anything in the openssl library directory. I figured out to compile my program with both -L and -R options without setting LD_LIBRARY_PATH and it worked fine. (I noticed it won't work without setting -R option) But the compiled program kept linking to /usr/local/ssl

Goal: create a shared library containing my CUDA kernels that has a CUDA-free wrapper/header. create a test executable for the shared library. Problem shared library MYLIB.so seems to compile fine. (no problem). Error in linking: ./libMYLIB.so: undefined reference to __cudaRegisterLinkedBinary_39_tmpxft_000018cf_00000000_6_MYLIB_cpp1_ii_74c599a1 simplified makefile: libMYlib.so : MYLIB.o g++ -shared -Wl,-soname,libMYLIB.so -o libMYLIB.so MYLIB.o -L/the/cuda/lib/dir -lcudart MYLIB.o : MYLIB.cu MYLIB.h nvcc -m64 -arch=sm_20 -dc -Xcompiler '-fPIC' MYLIB.cu -o MYLIB.o -L/the/cuda/lib/dir -lcudart

I started off creating libraries as shared libraries, but I considered it would be more efficient to create one shared libraries and the rest static. When it was all shared, it compiled and linked fine, but moving to static, I get on linking "undefined reference". Edit: I build all the libraries in one Android.mk Android.mk: MY_LOCAL_PATH := $(call my-dir) MY_LOCAL_CFLAGS := -DDEBUG TARGET_PLATFORM := 'android-4' LOCAL_PATH := $(MY_LOCAL_PATH)/../../Base include $(CLEAR_VARS) LOCAL_MODULE := Base LOCAL_SRC_FILES := <Base src files> include $(BUILD_STATIC_LIBRARY) MY_LOCAL_STATIC_LIBRARIES :=