dynamic-linking

Over the months I've written some nice generic enough functionality that I want to build as a library and link dynamically against rather than importing 50-odd header/source files. The project is maintained in Xcode and Dev-C++ (I do understand that I might have to go command line to do what I want) and have to link against OpenGL and SDL (dynamically in SDL's case). Target platforms are Windows and OS X. What am I looking at at all? What will be the entry point of my library if it needs one? What do I have to change in my code? (calling conventions?) How do I release it? My understanding is

I have a library that I got from a proprietary source and I'm trying to link against it but I'm getting the following error libxxx.so: file not recognized: File format not recognized collect2: ld returned 1 exit status and indeed $ ldd ./libxxx.so statically linked what does that exactly mean? Never saw a statically linked .so in my life. It might be worth noting that the last version of the same software included the same .so for which ldd shows the "normal" output and that works fine. $ file ./libxxx.so ./libxxx.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped but nm

I have a C++ library repeater.so that I can load from Python in Linux the following way: import numpy as np repeater = np.ctypeslib.load_library('librepeater.so', '.') However, when I compile the same library on Mac OS X (Snow Leopard, 32 bit) and get repeater.dylib , and then run the following in Python: import numpy as np repeater = np.ctypeslib.load_library('librepeater.dylib', '.') I get the following error: OSError: dlopen(/mydir/librepeater.dylib, 6): no suitable image found. Did find: /mydir/librepeater.dylib: mach-o, but wrong architecture Do I have to do something different to load a

I recently encountered this problem after an upgrade of the system: using the GCC -Wl,-rpath= option works differently than before. I used it to set the search paths to some shared libraries that were built in a sub-module of my project. At the time I considered it better than setting LD_LIBRARY_PATH system-wide (I didn't want to set it every time I turned on the computer). Everything worked fine, and these two approaches seemed equivalent. Now it seams that the behavior of -rpath has changed. It still works for directly dependent libraries, but not for those that link other libraries from the

gperftools documentation says that libprofiler should be linked into a target program: $ gcc myprogram.c -lprofiler (without changing a code of the program). And then program should be run with a specific environment variable: CPUPROFILE=/tmp/profiler_output ./a.out The question is: how does libprofile have a chance to start and finish a profiler when it is merely loaded, but its functions are not called? There is no constructor function in that library ( proof ). All occasions of "CPUPROFILE" in library code do not refer to any place where profiler is started. I am out of ideas, where to look

I need to use an alternate glibc version, newer than the one installed on my system ( 2.18 vs 2.15 ). Several related issues are covered here and here . The specific question I'm asking here is the following: I set up the library path of the new dynamic linker ( ld-2.18.so ) so that the new libc ( libc-2.18.so ) is found ahead of the old libc ( libc-2.15.so ). However, when I try to run a program with the new ld , the old version of libc is picked up, generating a SEGV . Why is that happening? Note: I know this can be fixed by using --rpath at compile time or LD_LIBRARY_PATH at run time.

If you have a very basic C++ program that only uses the 'cout' object, you can include iostream in the source file and then when you compile it you don't have to link any external libraries. In other words, you can simply run g++ main.cpp -c g++ main.o -o program ./program When you want to use more complicated objects such as threads, not only do you include pthread, but when you link the program you have to link to a library. g++ main.cpp -c g++ main.o -lpthread -o program ./program So my question is, why didn't I have to link any libraries to use all the iostream objects? You are linking to