shared-libraries | 易学教程

Static analysis tool to detect ABI breaks in C++

阅读更多关于 Static analysis tool to detect ABI breaks in C++

It's not very hard to break binary backwards-compatibility of a DSO/shared library with a C++ interface. That said, is there a static analysis tool, which can help detecting such ABI breaks, if it's given two different sets of header files: those of an earlier state of the DSO and those of the current state (and maybe DSOs as well)? Both free and commercial product suggestions are welcome. If it could also warn about bad practices, e.g. inline functions and defaulted function parameters in DSO interfaces, it would be great. Artyom I assume that you are familiar with this tutorial: Binary

How to create a shared library (.so) in an automake script?

阅读更多关于 How to create a shared library (.so) in an automake script?

问题 given some source file test.cpp I would like to create a shared library libtest.so . I am trying to do this within the scope of an automake file however I cannot seem to get this to work. For example under g++ I do the following: g++ -shared -fPIC test.cpp -o libtest.so then i can create another file that will depend on the shared library as follows: g++ mytest.cpp libtest.so -o blah I have read that automake only supports making shared libraries via libtool. I have tried to get my automake

use RPATH but not RUNPATH?

阅读更多关于 use RPATH but not RUNPATH?

This page - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - says about order for library search in ld.so: Unless loading object has RUNPATH: RPATH of the loading object, then the RPATH of its loader (unless it has a RUNPATH), ..., until the end of the chain, which is either the executable or an object loaded by dlopen Unless executable has RUNPATH: RPATH of the executable LD_LIBRARY_PATH RUNPATH of the loading object ld.so.cache default dirs And then suggest: When you ship binaries, either use RPATH and not RUNPATH or ensure LD_LIBRARY_PATH is set before they are run. So, using RPATH

android ndk UnsatisfiedLinkError when using a prebuilt shared library

阅读更多关于 android ndk UnsatisfiedLinkError when using a prebuilt shared library

问题 I'm trying to create a shared library that links to another shared library. Here is my main module Android.mk: TOP_LOCAL_PATH := $(call my-dir) include $(call all-subdir-makefiles) LOCAL_PATH := $(TOP_LOCAL_PATH) include $(CLEAR_VARS) LOCAL_CPP_EXTENSION := cpp LOCAL_C_INCLUDES := $(LOCAL_PATH)/include/ $(LOCAL_PATH)/lib/include LOCAL_MODULE := SightCore-jni LOCAL_SRC_FILES := SightDemo.cpp SightCore-jni.cpp LOCAL_SHARED_LIBRARIES := SightAPI LOCAL_LDLIBS = -llog include $(BUILD_SHARED

What's the accepted method for deploying a linux application that relies on shared libraries?

阅读更多关于 What's the accepted method for deploying a linux application that relies on shared libraries?

问题 I have an application that relies on Qt, GDCM, and VTK, with the main build environment being Qt. All of these libraries are cross-platform and compile on Windows, Mac, and Linux. I need to deploy the application to Linux after deploying on Windows. The versions of vtk and gdcm I'm using are trunk versions from git (about a month old), more recent than what I can get apt-get on Ubuntu 11.04, which is my current (and only) Linux deployment target. What is the accepted method for deploying an

Importing from a relative path in Python

阅读更多关于 Importing from a relative path in Python

I have a folder for my client code, a folder for my server code, and a folder for code that is shared between them Proj/ Client/ Client.py Server/ Server.py Common/ __init__.py Common.py How do I import Common.py from Server.py and Client.py? EDIT Nov 2014 (3 years later): Python 2.6 and 3.x supports proper relative imports, where you can avoid doing anything hacky. With this method, you know you are getting a relative import rather than an absolute import. The '..' means, go to the directory above me: from ..Common import Common As a caveat, this will only work if you run your python as a

How do applications resolve to different versions of shared libraries at run time?

阅读更多关于 How do applications resolve to different versions of shared libraries at run time?

I'm a noob to how shared libraries work on linux. I am trying to understand how do applications resolve different revisions of the same shared library at run-time on linux. As far as I understand, a shared library has three "names", for example, libmy.so.1.2 (real-name i.e. the actual obj file) libmy.so.1 (SONAME, which is embedded in the actual obj file) libmy.so (linker name, provided to the linker at link time and embedded in executable) When you install the library via LDCONFIG, it will create the following symbolic links (2) => (1) (3) => (2) Now lets say I compile another version of the

JS - Can't combine lib files

阅读更多关于 JS - Can't combine lib files

问题 I have multiple lib files in an an index.html file, that are loaded in proper sequence for an app I am running.  <script src="/./sys/lib/jquery.min.js"></script> <script src="/./sys/lib/jquery.ui.min.js"></script> <script src="/./sys/lib/jquery.easing.min.js"></script> <script src="/./sys/lib/underscore.min.js"></script> <script src="/./sys/lib/handlebars.min.js"></script> <script src="/./sys/lib/backbone.min.js"></script> <script src="/./sys/lib/moment.min

How to force symbols from a static library to be included in a shared library build?

阅读更多关于 How to force symbols from a static library to be included in a shared library build?

问题 I'm trying to build a shared object library that will be opened by a program using dlopen(). This library will use functionality provided by a separate library that is static. I have included the appropriate flag on the link line to pull in the static library when linking the dynamic one (e.g. I have -lfoo for libfoo.a), and the linker doesn't complain. However, when the main program calls dlopen() on the dynamic library, the call fails with an "undefined symbol" message referencing a symbol

Linking a shared library against a static library: must the static library be compiled differently than if an application were linking it?

阅读更多关于 Linking a shared library against a static library: must the static library be compiled differently than if an application were linking it?

问题 At least on Linux and Solaris, static libraries are really just a bunch of compiled .o's tossed into one big file. When compiling a static library, usually the -fpic flag is ommited, so the generated code is position dependent. Now say my static library is B. I've built it and have the resulting .a file which is really just a glob of all of the position dependent .o files. Now I have a shared library I'd like to build, A, and I want it to statically link B. When I build A, naturally I'll use