I hope that I have not led your attention too far astray with that voluminous compiler invocation. I use it to compile extensions which do a bit more than yours, and make use of the SQLite API to do so. The SQLITE_API qualifier is used to denote SQLite library entry points that are exposed, outside of the library itself, so that clients can call into the API by means of references that are resolved at link time. In this case, the linkage is into a dynamic load library, with linkages resolved at DLL load time. In that context, '__declspec(dllimport)' means 'create a reference (or address) to be resolved when the client code loads and either loads (or finds already loaded) the SQLite library as a DLL. By convention, extensions do not rely on linkage resolved that way; instead, they get a struct passed into them which contains all the API function addresses already resolved before the extension is loaded. If your extension works that way, (once it is made to actually do something), you will not need that particular define. It has been too long since I used clang for me to opine usefully on what it is complaining about. However, I can suggest that looking at the preprocessed form of your code can be very helpful when setting out to cure that sort of problem. If my posts on this have any relevance, it is to show that your problem lies in linkage issues rather than some mysterious failure of sqlite3\_load\_extension() to load a DLL and attempt to find the entry point it is given or must deduce as a default. As you can see, that works per that API's documentation. FWIW, I second Keith's recommendation that you use dumpbin.exe to sort out what has happened. With that tool, it is easy to see what names have actually been defined and compare those to the names reflecting to-be-resolved-at-link references. In addition to possible (but unlikely IMO) C versus C++ name decoration issues, you may be suffering from decoration variation with calling convention. Keywords to lookup on that are CDECL and STDCALL.