shared-libraries | 易学教程

Why does gcc force PIC for x64 shared libs?

阅读更多关于 Why does gcc force PIC for x64 shared libs?

问题 Trying to compile non-PIC code into a shared library on x64 with gcc results in an error, something like: /usr/bin/ld: /tmp/ccQ2ttcT.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC This question is about why this is so. I know that x64 has RIP-relative addressing which was designed to make PIC code more efficient. However, this doesn't mean load-time relocation can't be (in theory) applied to such code. Some online sources,

Can someone explain about Linux library naming?

阅读更多关于 Can someone explain about Linux library naming?

问题 When I create a library on Linux, I use this method: Build: libhelloworld.so.1.0.0 Link: libhelloworld.so.1.0.0 libhelloworld.so Link: libhelloworld.so.1.0.0 libhelloworld.so.1 The versioning is so that if you change the public facing methods, you can build to libhelloworld.so.2.0.0 for example (and leave 1.0.0 where it is), so that applications using the old library won't break. However, what's the point in naming it 1.0.0 - why not just stick with libhelloworld.so and libhelloworld.so.1?

How do I source/link external functions in C or C++?

阅读更多关于 How do I source/link external functions in C or C++?

问题 EDIT: I suppose I should clarify, in case it matters. I am on a AIX Unix box, so I am using VAC compilers - no gnu compilers. End edit I am pretty rusty in C/C++, so forgive me if this is a simple question. I would like to take common functions out of a few of my C programs and put them in shared libraries or shared objects. If I was doing this in perl I would put my subs in a perl module and use that module when needed. For the sake of an example, let's say I have this function: int

shared library text segment is not shareable

阅读更多关于 shared library text segment is not shareable

问题 I am trying to add HW video acceleration to a cm10.2 port for my device. I get no errors but the one below, then make stops working, apparently without any error. /home/vektor/CM102/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/ld: warning: shared library text segment is not shareable /home/vektor/CM102/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../.

Can't add dependency to Android Project

阅读更多关于 Can't add dependency to Android Project

I'm trying to add 'commons-validator' to my android project in Android Studio based on gradle. I use UrlValidator for my needs. So I add a dependency in build.gradle of an app module: dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:23.0.1' compile 'commons-validator:commons-validator:1.4.1' // this one } And uses-library to the AndroidManifest in application tag: <uses-library android:name="org.apache.commons.validator.routines.UrlValidator" android:required="true"/> But after adding it my project fails to Run. Error:Execution failed

Proxy shared library (sharedlib, shlib, so) for ELF?

阅读更多关于 Proxy shared library (sharedlib, shlib, so) for ELF?

问题 On Windows, it's more or less common to create "proxy DLLs" which take place of the original DLL and forward calls to it (after any additional actions as needed). You can read about it here and here for example. However, shlib munging culture under Linux is quite different. It starts with the fact that LD_PRELOAD is the builtin feature with ld.so under Linux, which simply injects separate shlib into process and uses any symbols it defines as override. And that "injection" technique seems to

dlopen with two shared libraries, exporting symbols

阅读更多关于 dlopen with two shared libraries, exporting symbols

问题 I have a linux shared library, foo.so, which is loaded from an executable using dlopen("foo.so", RTLD_NOW | RTLD_LOCAL) . From foo.so I'd like to dlopen another library, bar.so, which references symbols defined in foo.so, but the linker fails to find them. I can't change RTLD_LOCAL to RTLD_GLOBAL, because I don't have the source to the executable doing the loading. I thought -Wl,--export-dynamic when linking foo.so might help but it doesn't override the local flag to dlopen. GCC's new

On Linux, why does the destructor run twice on shared instance of global variable in C++?

阅读更多关于 On Linux, why does the destructor run twice on shared instance of global variable in C++?

问题 On Linux I have some generated C++ code from a static library that defines a global variable. A single instance of this global variable is shared between two shared libraries that refer to its symbol. When the process shuts down and the static termination phase is run, I see that the destructor on this shared instance is run twice! Presumably once per library as each unloads. This question is closely related to another I saw recently here: related question. This sounds like the same behavior,

Why do applications compiled by GCC always contain the _mcount symbol?

阅读更多关于 Why do applications compiled by GCC always contain the _mcount symbol?

问题 Libraries don't always contain the _mcount symbol, but applications do (you can verify this with gobjdump or the nm utility). I've read that _mcount is used to implement profiling, but the symbol is present even when profiling is disabled and optimization is enabled (-O2). Does it serve some other additional purpose? Update: I am on Solaris, so this is the Solaris linker combined with GCC, I'm not sure if that makes a difference or not. The GCC version is 4.2.2. This happens even if I compile

How is function main() inside a shared object (.so) taken care of by the linker?

阅读更多关于 How is function main() inside a shared object (.so) taken care of by the linker?

问题 Suppose I have an object file ( source.o ) without function main . a shared object ( libmain.so ) with function main . How will the linker take care of the entry point when both are linked dynamically to create binary source.bin ? 回答1: Whenever you have a dynamic linked program, there are several "entry points" involved. The first is in entry point of the dynamic linker itself, e.g. /lib/ld-linux.so.2 (on Linux/x86) or similar. The dynamic linker runs first, resolving all symbol names to