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

Reply via email to