On Sun, Mar 1, 2015 at 9:28 PM, James K. Lowden <jklowden at schemamania.org> wrote:
> On Sat, 28 Feb 2015 11:22:12 +0000 > Bart Smissaert <bart.smissaert at gmail.com> wrote: > > > It doesn't compile and gives linking errors: > > > > Error 1 error LNK2001: unresolved external symbol > > _sqlite3_db_filename > > C:\Users\Bart\SQLiteForExcel\Source\SQLite3_StdCall > > \SQLite3_StdCall.obj SQLite3_StdCall > > Error 2 error LNK1120: 1 unresolved > > externals C:\Users\Bart\SQLiteForExcel\Source\SQLite3_StdCall\Release > > \SQLite3_StdCall.dll 1 1 SQLite3_StdCall > > What you mean is, it *does* compile, and then the linker emits an > error. :-) > > > Strangely it doesn't point to a line in the block SQLITE3_STDCALL_API > > but points to line 1. > > Not strange, or anyway not too strange. The linker doesn't know from > source code. It only knows the object code references a symbol for > which it found no definition. > > The symbol you want, sqlite3_db_filename appears to be defined in > sqlite3ext.h, line 475: > > #define sqlite3_db_filename sqlite3_api->db_filename > > If you include that file, the linker shouldn't attempt to resolve > the symbol, because the preprocessor defines it away. > I do not know if this is the case, but typically Windows creates names like _sqlite3_db_filename at X (where X is a number) if a function is defined as stdcall. It doesn't *have* to do this, but that's the convention used by default. The fact that the error message is _sqlite3_db_filename instead of _sqlite3_db_filename at X makes me suspect that there is a prototype somewhere for the function that doesn't include stdcall. Perhaps the header and source files are out of sync? If that were the case, the @X version of the symbol might be in the obj file (the source file got stdcall right), while consumers using the header try to use the cdecl form without the @X (because the prototype is different in the two locations. I hope this isn't too rambling. Just thoughts from a sleep deprived person. :) -- Scott Robison
