Yes. Under most Unices, including Linux, these are known as ``shared objects'' and have .so extensions.

When compiling the object files that will go into them, you should use (assuming that you're using gcc) the -fpic option. This tells it to produce position independent code, which means that it doesn't matter where in memory it exists, and is very important if it will be used by more than one program at once.

When creating the shared object, you'll want to have your -o option specify a file named libsomething.so and also specify the option ``-shared''. This will created a shared object that can be dynamically linked to your executable.

You can have the final program then link it in via shared object function calls, but you more likely want to tell the runtime linker to deal with it. The problem with this is that shared objects have to be findable by the runtime linker itself, which is separate from your program. Most system libraries are held in well-known places (like /usr/lib, etc.), but you probably don't want to do that with this library. The program can tell the linker other places to look, though. If you know a directory that the program will be located in, then you should add a ``-rpath <libdir>'' to your final link to indicate where the library will be found. In order to specify the library at link time, you'll have to include the option ``-lsomething'', assuming that your library is of the name libsomething.so. The library need not be in the same place at link time it will be at run time, but it does need to be able to see a copy of it, and you can specify that using a ``-L <libdir>'' option to specify a directory where it can find shared objects.

(Note that at least some of these options are at least somewhat gcc/gnu ld specific.)