You simply link to SFML as with a normal application, choosing to build a library instead.
If you are building the library dynamically, you simply need both the SFML libraries (along with the required external libraries) and your library when running a program using your library. The program only needs to link to your library in this case, since it automatically loads the SFML ones. SFML then loads the external libraries, etc.
If you are building it statically, the library doesn't actually do any direct linking to SFML, and any program using your library has to link to SFML as well. In this case, when using Windows only the external libraries OpenAL32 and libsndfile need to be present (using linker options -static-libgcc and -static-libstdc++).
On Windows, the static SFML libraries use a special way of compiling the dependencies so that you don't have to link them in subsequent projects, but this requires rather advanced usage of CMake and may be rather difficult. This is defined in SFML/cmake/Macros.cmake.
This should be possible on Linux as well, but it's not officially supported, since static linking is rather uncommon on the platform. It's pretty useful for a more specific library, though.
As far as I know, for OS X SFML only officially supports XCode/LLVM which typically uses dynamic linking. Using gcc, it should be the same as on Linux.
