As you’ve noted, DYLD_LIBRARY_PATH behaves like LD_LIBRARY_PATH on other *nix. However, there is another environment variable you should look at called DYLD_FALLBACK_LIBRARY_PATH. In general, these are (both on osx and linux) suggested only for development use as they can cause symbol lookup errors when you override with a library that does not have the same … Read more
First of all, understand that an executable doesn’t contain a single rpath entry, but an array of one or more entries. Second, you can use otool to list an image’s rpath entries. Using otool -l, you’ll get output like the following, at the very end of which are the rpath entries: Load command 34 cmd … Read more
It’s a way to get code fix-ups (adjusting addresses based on where code sits in virtual memory, which may be different across different processes) without having to maintain a separate copy of the code for each process. The PLT, or procedure linkage table, is one of the structures which makes dynamic loading and linking easier … Read more
You can call the Go code from C. It is a confusing proposition, though. The process is outlined in the blog post you linked to. But I can see how that isn’t very helpful. Here is a short snippet without any unnecessary bits. It should make things a little clearer. package foo // extern int … Read more
This is a pretty famous difference between Windows and Unix-like systems. No matter what: Each process has its own address space, meaning that there is never any memory being shared between processes (unless you use some inter-process communication library or extensions). The One Definition Rule (ODR) still applies, meaning that you can only have one … Read more
To understand linkers, it helps to first understand what happens “under the hood” when you convert a source file (such as a C or C++ file) into an executable file (an executable file is a file that can be executed on your machine or someone else’s machine running the same machine architecture). Under the hood, … Read more
Use -l: instead of -l. For example -l:libXYZ.a to link with libXYZ.a. Notice the lib and .a are written out, as opposed to -lXYZ which would auto-expand to libXYZ.so/libXYZ.a. It is an option of the GNU ld linker: -l namespec … If namespec is of the form :filename, ld will search the library path for … Read more
There are (in most cases, discounting interpreted code) two stages in getting from source code (what you write) to executable code (what you run). The first is compilation which turns source code into object modules. The second, linking, is what combines object modules together to form an executable. The distinction is made for, among other … Read more
Dynamic linking can reduce total resource consumption (if more than one process shares the same library (including the version in “the same”, of course)). I believe this is the argument that drives its presence in most environments. Here “resources” include disk space, RAM, and cache space. Of course, if your dynamic linker is insufficiently flexible … Read more