shared-libraries

I'm trying to build a project using a static library, so that the binary can be used even if the library isn't installed. However, I get lots of errors about undefined symbols when I try to do so. Looking at the library, I see it has tons of undefined symbols, even though it's a .a static lib: nm - u /usr/local/lib/libthis.a .... U EVP_DigestFinal_ex U EVP_DigestInit_ex U EVP_DigestUpdate U EVP_MD_CTX_cleanup U EVP_MD_CTX_init Those seem to be from openssl; others seem to be from libbzip2; etc. Questions: 1. Why does the static ( .a ) lib have dependencies on shared objects (e.g. libopenssl)

I have a binary that uses a bunch of .so files. bash-3.00$ file foo foo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.21, dynamically linked (uses shared libs), not stripped But if I run ldd on this file, its not able to pick up the .so files the binary is dependent on.' bash-3.00$ ldd foo not a dynamic executable bash-3.00$ readelf does show the list of shared libraries used by the binary.. bash-3.00$ readelf -d foo Dynamic segment at offset 0x17c810 contains 70 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libdl.so.2] Why is ldd not able to

I am working on previously developed software and source code is compiled as linux shared libraries (.so) and source code is not present. Is there any tool which can extract source code from the linux shared libraries? Thanks, Ravi There isn't. Once you compile your code there is no trace of it left in the binary, only machine code. Some may mention decompilers but those don't extract the source, they analyze the executable and produce some source that should have the same effect as the original one did. You can try disassembling the object code and get the machine code mnemonics. objdump -D -

clang++ and g++ are ABI incompatible, even for things as core as standard containers, according to, e.g., the clang++ website. Debian ships with C++ shared libraries, i.e. libboost, etc... that are compiled with ~something and user programs using both compiler generally work, and the library names aren't mangled with the compiler that was used for them. When you install clang, debian doesn't go and pull in duplicate versions of every C++ library installed on your system. What's the deal? Is the ability of clang to link against distro-provided C++ libraries just way stronger than the

The issue is somewhat similar to this question but the accepted answer does not really propose a solution or workaround. In our project, we have a dylib and the main executalble. The dylib is compiled with -fno-rtti , while the executable does use RTTI. The problem happens when an exception (e.g. std::bad_alloc ) is thrown from the dylib and is caught in the exe. (Before you yell "exceptions need RTTI so you must have it on!", please note that the RTTI necessary for exceptions is always generated regardless of the -frtti or -fno-rtti setting. This is actually documented in the -fno-rtti flag

The problem I faced has been solved here: Loading shared library in open-mpi/ mpi-run I know not how, setting LD_LIBRARY_PATH or specifying -x LD_LIBRARY_PATH fixes the problem, when my installation itself specifies the necessary -L arguments. My installation is in ~/mpi/ I have also included my compile-link configs. $ mpic++ -showme:version mpic++: Open MPI 1.6.3 (Language: C++) $ mpic++ -showme g++ -I/home/vigneshwaren/mpi/include -pthread -L/home/vigneshwaren/mpi/lib -lmpi_cxx -lmpi -ldl -lm -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl $ mpic++ -showme:libdirs /home/vigneshwaren/mpi/lib

We are thinking to move our ci from jenkins to gitlab. We have several projects that have the same build workflow. Right now we use a shared library where the pipelines are defined and the jenkinsfile inside the project only calls a method defined in the shared library defining the actual pipeline. So changes only have to be made at a single point affecting several projects. I am wondering if the same is possible with gitlab ci? As far as i have found out it is not possible to define the gitlab-ci.yml outside the repository. Is there another way to define a pipeline and share this config with

Although a few solutions exist on the internet, I found none of those suitable for the problem I'm curerntly facing (though maybe I'm simply too dumb): I'm trying to build an R package which makes extensive use of a shared object compiled by a Makefile (yes, bad practice, I know, but a Makevars file just can't be told to compile C and Fortran code into one shared object) from code in the package's src directory. No matter where I compile that .so to (I tried the src , libs and package base folders) or how I name it (as one of the solutions mentioned above states it must be named like the

The pimpl idiom is commonly used in order to allow changing code in dynamically linked libraries without breaking ABI compatibility and having to recompile all the code that depends on the library. Most of the explanations I see mention that adding a new private member variable changes the offsets of public and private members in the class. That makes sense to me. What I don't understand is how in practice this actually breaks the dependent libraries. I've done a lot of reading on ELF files and how dynamic linking actually works, but I still don't see how changing the class size in the shared