Note: FIXME:The following is not up-to-date.
To link an executable you need to link together: your object files, any Windows libraries that your application depends on, gdi32 for instance, and any additional library that you use. All the libraries you link with should be available as '.so' libraries. If one of them is available only in '.dll' form then consult Building WineLib DLLs.
It is also when attempting to link your executable that you will discover whether you have missing symbols or not in your custom libraries. On Windows when you build a library, the linker will immediately tell you if a symbol it is supposed to export is undefined. In Unix, and in Winelib, this is not the case. The symbol will silently be marked as undefined and it is only when you try to produce an executable that the linker will verify all the symbols are accounted for.
So before declaring victory when first converting a library to Winelib, you should first try to link it to an executable (but you would have done that to test it anyway, right?). At this point you may discover some undefined symbols that you thought were implemented by the library. Then, you to the library sources and fix it. But you may also discover that the missing symbols are defined in, say, gdi32. This is because you did not link the said library with gdi32. One way to fix it is to link this executable, and any other that also uses your library, with gdi32. But it is better to go back to your library's makefile and explicitly link it with gdi32.
As you will quickly notice, this has unfortunately not been (completely) done for Winelib's own libraries. So if an application must link with ole32, you will also need to link with advapi32, rpcrt4 and others even if you don't use them directly. This can be annoying and hopefully will be fixed soon (feel free to submit a patch).