Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2013-12

how to install sqlite server side library on CentOS

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Dennis Poon

My server program written in fpc uses sqlite3 and
in ubuntu, I just need to
apt-get install libsqlite3-dev

but in centos, the libsqlite3-dev does not exist and the client lib after yum install sqlite
was not enough.

The server program still complained: libsqlite3.so is missing.

Please help.

Dennis

Reply by email

Jonas Maebe
to Dennis Poon
Dennis Poon wrote 10 lines
My server program written in fpc uses sqlite3 and in ubuntu, I just need to apt-get install libsqlite3-dev but in centos, the libsqlite3-dev does not exist and the client lib after yum install sqlite was not enough. The server program still complained: libsqlite3.so is missing.

The default behaviour of almost all FPC database units is buggy in the sense that they look for *.so instead of for *.so.0, *.so.1 or similar files. The *.so file indeed only exists if you install the development addendum of a package, and it's just a symlink to the latest supported version (which is a *.so.0, *.so.1 or similar file). The only purpose of such a symlink is that in case you link to a library at compile time, the program will be linked against this latest installed version (under the assumption that it was also compiled using the .h files installed on the system, which belong to this same latest installed version). They should definitely never be used for dynamic loading, because a) they generally do not (and should not) exist on user systems b) they could point to any version, and the unit loading it may not support that version

In case of FPC, they actually shouldn't be used in case of compile-time linking either because of point b) above, and we should again explicitly link to specific versions.

Anyway, you can work around the specific problem you are having by telling the sqlite unit to use the specifically supported version by calling InitialiseSQLite('libsqlite.so.0'). It will work on both Ubuntu and CentOS and any other Linux distribution, and no one will have to install any -dev packages.

Jonas

Reply by email

Dennis Poon
to Jonas Maebe
Jonas Maebe wrote 23 lines
On 06 Dec 2013, at 18:45, Dennis Poon wrote: > My server program written in fpc uses sqlite3 and > in ubuntu, I just need to > apt-get install libsqlite3-dev > > but in centos, the libsqlite3-dev does not exist and the client lib after > yum install sqlite > was not enough. > > The server program still complained: libsqlite3.so > is missing. > The default behaviour of almost all FPC database units is buggy in the sense that they look for *.so instead of for *.so.0, *.so.1 or similar files. The *.so file indeed only exists if you install the development addendum of a package, and it's just a symlink to the latest supported version (which is a *.so.0, *.so.1 or similar file). The only purpose of such a symlink is that in case you link to a library at compile time, the program will be linked against this latest installed version (under the assumption that it was also compiled using the .h files installed on the system, which belong to this same latest installed version). They should definitely never be used for dynamic loading, because a) they generally do not (and should not) exist on user systems b) they could point to any version, and the unit loading it may not support that version In case of FPC, they actually shouldn't be used in case of compile-time linking either because of point b) above, and we should again explicitly link to specific versions. Anyway, you can work around the specific problem you are having by telling the sqlite unit to use the specifically supported version by calling InitialiseSQLite('libsqlite.so.0'). It will work on both Ubuntu and CentOS and any other Linux distribution, and no one will have to install any -dev packages.

Jonas,

Thanks so much for your help but I tried putting
InitialiseSQLite('libsqlite.so.0')
which did not work.

then I realised, you probably meant
      InitialiseSQLite('libsqlite3.so.0');

However, it then complained that "SQLIte interface already initialized from library libsqlite3.so.0."

I seached files: sqlite3conn.pp, sqlite3dyn.pp, sqlite3.inc, dynlibs.inc but could not find where InitializeSQLite was called so could not replace that call from '.so' to '.so.0 '

However, I did find the default library name, used by the function InitiliseSQLite if no parameter is passed to it, which is composed of a default file extension defined in file dynlibs.inc

    const   SharedSuffix = 'so';

Since it is a constant, I dared not change it.

Eventually, I used command
find / -name 'libsqlite3.so*'

and found on this CentOS 64 bit machine:

/usr/lib64/libsqlite3.so.0
/usr/lib64/sw/sqlite37/libsqlite3.so.0
/usr/lib64/sw/sqlite37/libsqlite3.so.0.8.6
/usr/lib64/libsqlite3.so.0.8.6

so, I created a symbolic link in /usr/lib64/
ln -s libsqlite3.so.0 libsqlite3.so

and finally, it worked!

I don't know enough about database in FPC to suggest an improvement scheme but I do think such one is really in needed for future users.

Thanks Jonas for your help.

Dennis

Reply by email

LacaK
to Dennis Poon

Dennis Poon wrote / napísal(a):

Show quoted text 86 lines
Jonas Maebe wrote: > On 06 Dec 2013, at 18:45, Dennis Poon wrote: > > >> My server program written in fpc uses sqlite3 and >> in ubuntu, I just need to >> apt-get install libsqlite3-dev >> >> but in centos, the libsqlite3-dev does not exist and the client lib >> after >> yum install sqlite >> was not enough. >> >> The server program still complained: libsqlite3.so >> is missing. >> > The default behaviour of almost all FPC database units is buggy in > the sense that they look for *.so instead of for *.so.0, *.so.1 or > similar files. The *.so file indeed only exists if you install the > development addendum of a package, and it's just a symlink to the > latest supported version (which is a *.so.0, *.so.1 or similar file). > The only purpose of such a symlink is that in case you link to a > library at compile time, the program will be linked against this > latest installed version (under the assumption that it was also > compiled using the .h files installed on the system, which belong to > this same latest installed version). They should definitely never be > used for dynamic loading, because > a) they generally do not (and should not) exist on user systems > b) they could point to any version, and the unit loading it may not > support that version > > In case of FPC, they actually shouldn't be used in case of > compile-time linking either because of point b) above, and we should > again explicitly link to specific versions. > > Anyway, you can work around the specific problem you are having by > telling the sqlite unit to use the specifically supported version by > calling InitialiseSQLite('libsqlite.so.0'). It will work on both > Ubuntu and CentOS and any other Linux distribution, and no one will > have to install any -dev packages. > > Jonas, Thanks so much for your help but I tried putting InitialiseSQLite('libsqlite.so.0') which did not work. then I realised, you probably meant InitialiseSQLite('libsqlite3.so.0'); However, it then complained that "SQLIte interface already initialized from library libsqlite3.so.0." I seached files: sqlite3conn.pp, sqlite3dyn.pp, sqlite3.inc, dynlibs.inc but could not find where InitializeSQLite was called so could not replace that call from '.so' to '.so.0 ' However, I did find the default library name, used by the function InitiliseSQLite if no parameter is passed to it, which is composed of a default file extension defined in file dynlibs.inc const SharedSuffix = 'so'; Since it is a constant, I dared not change it. Eventually, I used command find / -name 'libsqlite3.so*' and found on this CentOS 64 bit machine: /usr/lib64/libsqlite3.so.0 /usr/lib64/sw/sqlite37/libsqlite3.so.0 /usr/lib64/sw/sqlite37/libsqlite3.so.0.8.6 /usr/lib64/libsqlite3.so.0.8.6 so, I created a symbolic link in /usr/lib64/ ln -s libsqlite3.so.0 libsqlite3.so and finally, it worked! I don't know enough about database in FPC to suggest an improvement scheme but I do think such one is really in needed for future users.

Did you have tried :

  SQLiteLibraryName := 'libsqlite3.so.0';  // SQLiteLibraryName is
defined in sqlite3conn.pp
or
  sqlite3dyn.SQLiteDefaultLibrary := 'libsqlite3.so.0';

-Laco.

Reply by email