I googled for "just enough C" (good book name, alas, taken) and found this, which looks very useful but does not cover shared libraries:
http://www.slideshare.net/petdance/just-enough-c-for-open-source-programmers > Regarding the shared library part, you could probably live only knowing it > is a way of exporting symbols from a binary file (.so on Linux, .dll on > Windows, .dylib on OS X) in a way other programs can use them. Let me try to expand on that a little bit.: A shared library is a binary file with a structured format. The details aren't super important here, but for completeness/further googling, the formats are called ELF (Linux), PE (Windows), and MachO (OS X). The important thing is that each of these formats has a header describing the rest of the file. To take ELF as an example (the others are very similar), each "libname.so" ELF file contains a list of segments specified as addresses (in bytes -- think of "seeking" in a file). There are several types of segments, each with it's own header and sub-structure. This is all agreed upon and documented as a foundational part of the OS, so compilers, linkers, and loaders can inter-operate on a given system. There is also a special "section" entry called a symbol table (one per file), which is a map from a name to yet another address in the .so file. When a C file is compiled into a shared library, each function defined in the file gets it's own entry in the symbol table (to a first approximation - as always, there are details). Here's where the "shared library" part comes from: many programs use the same set of primitives implemented in C. Shared libraries were invented to allow such code ("printf", or Cocoa window drawing calls, or OpenGL) to be loaded by multiple programs from a single file, and to be used simultaneously with only one copy in memory. This is still important today, but was critical on relatively resource-constrained systems in the past. The alternative is to compile all of the functions a program needs in to one large (often much, much larger) file; that approach is called "static linking", whereas the shared library approach is called "dynamic linking". The way this comes together is that when one writes: ccall( (:puts, "libc"), Void, (Ptr{Uint8},), "hello, world") > The first thing that happens [1] is that Julia asks the "dynamic linker" for a symbol called "puts" in the library named "libc" (the shared library for the C standard library). The linker goes to the symbol table and finds the corresponding address (skipping over relocation [2,3]). Julia then uses this address to make the C-style function call with the specified argument passed along. One important detail when writing your own C code is "symbol visibility": some symbols are exported and can be used by other code, whereas other symbols are private (see also: global vs. local symbols). If you are using existing libraries with a decent build system, then hopefully this won't be too much of a problem. [Ok, well this ran long... but hopefully it is helpful. If nothing else, having a high-level overview and a few more keywords to try makes searching google and stackoverflow much more productive] [1] well, eventually: http://stackoverflow.com/questions/5162580/what-happens-when-a-computer-program-runs [2] http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/ [3] links to various tutorials and tools, and a nice overview of some deeper details: http://jvns.ca/blog/2013/12/10/day-40-learning-about-linkers/ On Fri, Aug 15, 2014 at 2:15 PM, João Felipe Santos <[email protected]> wrote: > I once wrote a simple example of how to write and compile C code as a > shared library and call from Julia using ccall. I could share it if you are > interested, although it has no documentation at all at the moment besides a > couple of comments. > > Main things you have to know from C are types, structs, arrays and > pointers, passing arguments to functions by value and by reference, and the > basics of memory allocation (this is almost the whole language, excluding > standard libraries and quirkier parts of C99). > > Regarding the shared library part, you could probably live only knowing it > is a way of exporting symbols from a binary file (.so on Linux, .dll on > Windows, .dylib on OS X) in a way other programs can use them. > > I may have simplified or overcomplicated things, but I think these are the > basic concepts one would need to write code that uses a shared library. > > -- > João Felipe Santos > > > On Fri, Aug 15, 2014 at 1:15 PM, Randy Zwitch <[email protected] > > wrote: > >> I know the standard recommendation of K&R for people who want to learn C. >> But what would people's recommendations be to learn *just enough* C to be >> comfortable using C libraries from within Julia? For example, the manual >> states: >> >> "The code to be called must be available as a shared library. Most C and >> Fortran libraries ship compiled as shared libraries already... " >> >> Having done almost nothing in C, this statement doesn't help me a whole >> lot, since I don't know what a shared library is. For instance, I've come >> across a few .h files as open-source projects, but I think the above >> statement is referring to .so files? >> >> So any recommendations how can I get enough knowledge about C to use >> ccall if I desire, without taking a ton of time away from Julia? I also >> know Python and R as a frame of reference. >> > >
