On Sun, Sep 25, 2011 at 7:04 PM, JFC Morfin <jef...@jefsey.com> wrote:
> At 02:44 26/09/2011, Simon Slavin wrote: > > On 26 Sep 2011, at 1:35am, JFC Morfin wrote: >> >> > I have copied the C programe in >> > http://sqlite.org/quickstart.**html<http://sqlite.org/quickstart.html>and >> > tried to compile it. >> > With BorlandC, TCC, and now MinGW. >> > I obtain the unique same error: "undefined symbol (or reference): >> sqlite3_version". >> > >> > As I see in the sql code that "SQLITE_API const char sqlite3_version[] >> = SQLITE_VERSION;" is in line 693 and 110173 (ifndef SQLITE_AMALGAMATION >> which is defined in line 21)., I do not understand the problem. Suspecting >> it might be something related to the last version I looked in vain into the >> list archives of the last two months list. >> > > Hi! Simon, > Thank you for helping. > > > Did you include the amalgamation source code in with your program ? I >> don't mean just put it in the right folder, but also tell your compiler that >> both the C code and the header are part of your project. >> > > > I think so: I entered > > #include "c:\sqlite\sqlite3.h" > #include "c:\sqlite\sqlite3.c" > > at the begining of the file. > This is wrong for a number of reasons. The first thing you should do is study the vendor's documentation on project files. Usually, there is an additional file deposited into the directory which explicitly lists all source code files which should be compiled & linked into the final binary. I suspect the author is not aware of this. Using #include to merge all source files together is done to bypass project files. Sometimes this works, but most of the time this doesn't as the errors cited above attest. Including source files into other source files via #include is *not* the way to define a project for a number of reasons. Best practice in C/C++ programming shows that use of #include should be limited to header files only. The reason for this dictum is that all compilers have limits as to how much code can be processed to create an object file. Merging one source code file into another may exceed what the compiler can translate in one translation unit context. A second reason for not merging source files together is that the scoping landscape intended by the original authors may be compromised. As an example, consider global static variables defined within a single .c file. These variables were initially intended to be global for only the file where they were defined. By including that file into another, the intended scope is now inadvertently broadened. "undefined symbol" denotes linker errors -- meaning that the linker is unable to match the name of symbols needed in any given object file with the symbols defined in other object files in the project. I don't know the code which is being compiled, but I suspect that the variable in question is defined globally within the file. One would think that including source files together as naively done here would resolve this, but consider the ramifications if this project is being compiled as C++ code which will decorate names. I suspect (without verification...) that the amalgamation has some extern "C" constructs in either the header or source files. This signals the compiler to treat the code as C code (unmangled) as opposed to decorated C++ code. While all code may very well compile, the linker cannot merge all object files into a coherent binary because all encountered files do not contain matching symbols. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users