Re: GNAColl SQLite Binding Installation Problem (Mac, Snow Leopard)

[Simon Wright <simon@pushface.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 13 Aug 2011 18:05:36 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Thu, 11 Aug 2011 13:04:07 +0100, Simon Wright wrote:
>>>
>>>> Alexander Korolev <antonovkablog@gmail.com> writes:
>>>> 
>>>>> == To run, set the environment variable LD_LIBRARY_PATH
>>>>> ==   LD_LIBRARY_PATH=/usr/local/gnatcoll/lib/gnat:$LD_LIBRARY_PATH
>>>> 
>>>> Of course, on Mac OS X that would be DYLD_LIBRARY_PATH. But I don't
>>>> think you'll need it. In any case, you've just built static-only!
>>>
>>> Especially because the intended use of SQLite is the "amalgation"
>>> source file compiled and statically linked to the application.
>> 
>> I don't think it's quite so clear-cut as that:
>> http://www.sqlite.org/amalgamation.html.
>> 
>> For all we know libsqlite3.dylib was produced from the amalgamation, so
>> you might get the 5-10% performance improvement anyway (if you really
>> need it).
>
> I think that performance is not so relevant here, as the nature of
> SQLite, which is an embeddable RDBMS/Client. If not for this case,
> there is little sense to deploy SQLite at all.

GNATcoll generates -lsqlite3 at link time. So you will be using a
library if you want to run (or test) with unmodified GNATcoll.

Mac OS X happens to incorporate SQLite as a shared library, not that it
matters.

This has nothing to do with how you might configure an embedded system,
of course.

[OP's problem was with libgnatcoll_sqlite, not with libsqlite3.]