It doesn't really matter if the program you are using creates the binary equivalent of a DLL. VLC and MPlayer both use hackery to load windows DLLs that process film, but they can't directly use these DLLs. The same is true with the DLL your program creates. It is useless in OS X.
dylib is just the name of the dynamic linker that loads and also builds shared libraries.
You need to search on how to create an archive using gcc.
If the code you have been comes from a project on Windows and it requires a DLL you are in a seriously bad situation. Windows users don't expect to load an Apple app say like iMovie and expect it to work since the underlying hardware is identical.
Here is how to to build both a static and shared version of some example code
int add_0(int number) {
return (number + 0)
}
This is in a file called src0.c You could also create src1.c through to scr5.c that do the same thing but add a different value.
cc -g -c src*.c
This will create 5 src*.o files
ar crl libaddnum.a *.o
This creates the archive libaddnum.a, but it can't be used yet as there is no index.
ranlib libaddnum.a. You now have a working library that you will link against at compile time. This is the old fashioned way as the library when compiled against your program will be added the resulting binary. If the library was say 1024mbytes and you had 10 programs using that binary, they would together consume 10 gigs of HD space with no apparent performance boost.
Here is how to do the same task with shared libs
ld -dynamic -o libaddnum.dylib *.o
cc -g useprog.c libaddnum.dylib
The dynamic lib libaddnum is now linked at runtime and is not part of the programs size. So say like the previous example, if the library was 1024mbytes and you had 10 programs. The resulting space would be 1100mbytes. A saving of 10 fold.
If this doesn't help you, then you really need to get a book on building shared libs in Unix.
