shared-libraries

I'm trying to compile the following simple DL library example code from Program-Library-HOWTO with g++. This is just an example so I can learn how to use and write shared libraries. The real code for the library I'm developing will be written in C++. #include <stdlib.h> #include <stdio.h> #include <dlfcn.h> int main(int argc, char **argv) { void *handle; double (*cosine)(double); char *error; handle = dlopen ("/lib/libm.so.6", RTLD_LAZY); if (!handle) { fputs (dlerror(), stderr); exit(1); } cosine = dlsym(handle, "cos"); if ((error = dlerror()) != NULL) { fputs(error, stderr); exit(1); }

what is the relation between shared object( .so ) file and object( .o ) file? can you please explain via example? quark Let's say you have the following C source file, call it name.c #include <stdio.h> #include <stdlib.h> void print_name(const char * name) { printf("My name is %s\n", name); } When you compile it, with cc name.c you generate name.o . The .o contains the compiled code and data for all functions and variables defined in name.c, as well as index associated their names with the actual code. If you look at that index, say with the nm tool (available on Linux and many other Unixes)

I know .o are object files, .a are static libraries and .so are dynamic libraries? What is their physical significance? When can I use some and when not? .a is an "archive". Although an archive can contain any type of file, in the context of the GNU toolchain, it is a library of object files (other toolchains especially on WIndows use .lib for the same purpose, but the format of these is not typically a general purpose archive, and often specific to the toolchain). It is possible to extract individual object files from an archive which is essentially what the linker does when it uses the

Is it possible to create a Shared Library (.so) using Go? UPDATED : created an " issue " for it. Reza This is possible now using -linkshared flag What you need to do is to first run this command: go install -buildmode=shared -linkshared std (Above code makes all common packages shareable!) then go install -buildmode=shared -linkshared userownpackage finally when compiling your code you need to run: go build -linkshared yourprogram What the above those is now it rather than statically linking everything only dynamically links them and you will end up with much smaller compiled files. Just to

How do I find out which functions of a shared object are used by a program or an other library? In this specific case, I would like to see which functions in /lib/libgcc1_s.so.1 are used by an other dynamic library. Since they are dynamically linked, objdump -d doesn't resolve the function call addresses. Is there a way short of running the program in a debugger or relinking statically? Thanks, Luca Edit: nm and readelf won't do, I don't need to see which symbols are present in a shared object, but which are actually used in an other object that links to it. nm will only work if the library

glibc provides backtrace() and backtrace_symbols() to get the stack trace of a running program. But for this to work the program has to be built with linker's -rdynamic flag. What is the difference between -g flag passed to gcc vs linker's -rdynamic flag ? For a sample code I did readelf to compare the outputs. -rdynamic seems to produce more info under Symbol table '.dynsym' But I am not quite sure what the additional info is. Even if I strip a program binary built using -rdynamic , backtrace_symbols() continue to work. When strip removes all the symbols from the binary why is it leaving

We are using an third party static library, let say A.a for android development. We link it as shared library and it works fine in the one App, but when use B.so to build another C.so , some symbols in A.a cannot find. We have already use -Wl,--export-dynamic and -Wl,--whole-archive to build B.so . We have using nm to check those symbols, it exist but list as “t” instead of “T” ，which means it is local symbols instead of external. Seams the A.a are build with -fvisibility=hidden after som investigation. But because some reason it is hard for us to got an new build library immediately, so we

I'm trying to compile a minimal shared library and link to it and have been failing for two hours now. Here is ALL the code: // rect.h class Rect{ private: int width_, height_; public: Rect(int width, int height); int width(); int height(); }; // rect.cpp #include "rect.h" Rect::Rect(int width, int height) :width_(width), height_(height){} int Rect::width() { return width_; } int Rect::height() { return height_; } // client.cpp #include "rect.h" #include <iostream> int main() { std::cout << Rect(1,2).width(); return 0; } And this is how I try to compile it: $ g++ -shared -o librect.so rect.cpp