At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.
I'll name the library libgeorge - a general purpose C library. Btw is there something like a Comprehensive C Archive Network where I can easily search for handy C libraries built by others? I know there are other general purpose ones like glib by GNOME and other GNU stuff, but I don't know if there's something like boost for C.
If you're working on a Linux system with gcc, you'll first need to compile the source files into object files (e.g. gcc -c sorting.c will create the sorting.o object file). Afterwards you can use `gcc -shared -o library.so sorting.o' to create a shared library.
what about the lib*.a files (created with `ar' I think) I see among the lib*.so files? What's the difference between the .a and the .so files?
I believe the .a extension is for archive files. This page was interesting: http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html
is this about creating .h files?
I think the main difference between .so and .a files are the moment they are linked. .so files are linked during runtime (dynamic linking, when you're executing a program, much like Windows DLLs). .a files are linked at the moment you're compiling the program (static linking). Dynamic linking has a bit more overhead, but your program will benefit from any updates to the library. With static linking, the library becomes part of your program and is not updatable (except for recompilation).
Ah so things like shared objects are what lets me update and upgrade my linux boxes without ever rebooting? :D
Another thing: how do I make my library cross-platform? I didn't use any linux or GNU stuff in my code, so I want it to be available on BSD, proprietary UNIX, OSX, ARM, MIPS, PowerPC, SPARC, m68k, Windows, etc.
I guess I need to make a libgeorge.h header file as well as the libgeorge.dll, libgeorge.so, and libgeorge.a files available. How do I write an installer so that the linkers on those systems know where the libgeorge files are? I guess it's not that trivial making a cross-platform C library, let alone a single-platform one :(
As far as rebooting after updates, I use that as a metric of how good an application is. IMO, the only reason to reboot after an update is to move a new kernel into place. Anything else can and should be able to restart without rebooting. Programs and daemons (especially web browsers like Safari and IE) should be held at arms length by the kernel/OS. As such, there is no way that a well written program can need a reboot of the kernel/OS after an update. Web browsers, and anything else that directly processes Internet data, are especially dangerous because they process untrusted, unverified and sometimes malicious data. They should be held especially far away from the kernel/OS.
Shared objects are what lets you update your system without recompiling it entirely. Imagine having to recompile all the software on your computer each time there is an update to a library. If you want to release your library cross-platform, you'll need to figure out what kind of libraries are used on those platforms (.so on most Unix machine, .dll on Windows etc.) and compile the library in each format. As you mention, releasing a header file is also a requirement. Without it, nobody would know how to use your library. As for installing, I can only talk about Linux again. The system will find your library automatically if it's placed inside the /usr/lib/ directory most of the time. Header files can be put in /usr/include/. The actual folder for the library might differ slightly, depending on the distribution that is used.