sqlite3 module: how to maintain lib paths

[rickyboy]

Hello everyone,



I recently had to test an application of the sqlite3 module and when I first ran the application, it complained about not being able to find the library.



Here is the code from the module that contains various possible locations of where the library could be, and uses that to check one-by-one if they exist on the system.

Code Select Expand

; set library to path-name of the library on your platform OS
;
(set 'files (list
        "/usr/lib/libsqlite3.so" ; SuSE Linux
        "/usr/local/lib/libsqlite3.so" ; Linux, BSD, Solaris
        "/usr/pkg/lib/libsqlite3.so" ; NetBSD
        "/usr/local/lib/libsqlite3.so.13.3" ; OpenBSD 4.6
        "/usr/lib/libsqlite3.0.dylib" ; Mac OSX Darwin
        "/usr/lib64/libsqlite3.so" ; for 64Bit CentOS 6 Linux
        (string (env "PROGRAMFILES") "/sqlite3/sqlite3.dll") ; Win32/MinGW
))


(set 'library (files (or
                       (find true (map file? files))
                       (throw-error "cannot find sqlite3 library"))))
I was running on an Ubuntu 12.04 box and this yielded yet another location (everybody *HAS* to do things differently, eh? :)).  Here's the location I had to add, in diff form.

Code Select Expand

$ git diff HEAD^ HEAD
diff --git a/modules/sqlite3.lsp b/modules/sqlite3.lsp
index 66b8b2c..c53a798 100644
--- a/modules/sqlite3.lsp
+++ b/modules/sqlite3.lsp
@@ -87,6 +87,7 @@
        "/usr/local/lib/libsqlite3.so.13.3" ; OpenBSD 4.6
        "/usr/lib/libsqlite3.0.dylib" ; Mac OSX Darwin
        "/usr/lib64/libsqlite3.so" ; for 64Bit CentOS 6 Linux
+        "/usr/lib/x86_64-linux-gnu/libsqlite3.so" ; for Ubuntu 12.04
        (string (env "PROGRAMFILES") "/sqlite3/sqlite3.dll") ; Win32/MinGW
 ))
I don't know who maintains the module, but maybe they'd like to know; however, for anybody sake, here's the kludge to get you by on Ubuntu 12.04.  Who knows how many more places that the distros (or rather package maintainers can put their libraries).  The decision is not mine to make what the module should be doing here; so, I'll stop here. As the father said in the movie My Big Fat Greek Wedding, "Therrrre you go!"  :)

[jazper]

Thanks, rickyboy, it's good to have that in print so we can search for it.  As an Ubuntu user, I have had to do this many times.  In fact, the location of the .so file has even changed at least once that I can remember on Ubuntu itself.  



I did not think of putting it in print here - perhaps I have a low opinion of my skill at this sort of thing, or maybe I was always in a hurry.  But, it's really great to know "I read about that" somewhere in the back of our minds.



Next time I encounter a funny, I'll try to remember to post about it.

[Lutz]

Thanks for the update Rickyboy, now online here:



http://www.newlisp.org/code/modules/sqlite3.lsp.html">http://www.newlisp.org/code/modules/sqlite3.lsp.html

[bairui]

There is the

Code Select Expand

/usr/lib/i386-linux-gnu/libsqlite3.so.0

analogue too...   :-/



This bit me yesterday when I was testing jazper's sqlite3 stuff. I whimped out and created a symlink from /usr/local/lib/libsqlite3.so, but that really was just a kludge.

[xytroxon]

One more...

Code Select Expand


   ...
    (string (env "PROGRAMFILES") "/sqlite3/sqlite3.dll") ; Win32/MinGW
    "sqlite3.dll" ; <- look in the same directory as the script
))


Looking in the same directory as the script would be useful for 'all in one' packages, so you don't need to explain to your 'low info' user how to manually install sqlite3.dll in a non-standard manor on Windows...



Also useful when testing newer or non-standard versions of sqlite3.dll and in maintaining version control of the sqlite3.dll



Or should "sqlite3.dll" be the first file in the list checked to allow overriding the other search locations on other systems too?



Thanks...



-- xytroxon

[jazper]

On Ubuntu 12.10, I have two .so files on /usr/lib/x86_64-linux-gnu/:

Code Select Expand

libsqlite3.so.0
libsqlite3.so.0.8.6
I chose the first, but I confess to have hovered over that: can one assume that 0.8.6 is an advance on the other?  I tend to trust cosy integers when it comes to version numbers (if that is what this is).  I couldn't find any advice by googling at the time.  The DEB package list reflects both, but there is no advice on what each one does.

[rickyboy]

jazper,



On mine they are the same because one is symlinked to the other.

Code Select Expand

$ ls -la /usr/lib/x86_64-linux-gnu/libsqlite3.*so*
lrwxrwxrwx 1 root root     19 Aug  7 16:39 /usr/lib/x86_64-linux-gnu/libsqlite3.so -> libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root     19 Jan  5 02:09 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rw-r--r-- 1 root root 664504 Aug  7 16:39 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6

By the way, sorry that I didn't check 12.10 last night. :( I will try again later today.

[rickyboy]

There is the

Code Select Expand

/usr/lib/i386-linux-gnu/libsqlite3.so.0
analogue too...   :-/



This bit me yesterday when I was testing jazper's sqlite3 stuff. I whimped out and created a symlink from /usr/local/lib/libsqlite3.so, but that really was just a kludge.

Symlinking is a good solution.  Actually I prefer doing that to changing the module code.  Thanks!



Also, you bring up a good point about the 32-bit versus 64-bit libraries.  This complicates the issue of the module code trying to find the right version of the library for the user seamlessly.

[Lutz]

This is what is online at: http://www.newlisp.org/code/modules/sqlite3.lsp.html">http://www.newlisp.org/code/modules/sqlite3.lsp.html since yesterday around noon (version 2.82):

Code Select Expand

(set 'files (list
    "/usr/lib/libsqlite3.so" ; SuSE Linux
    "/usr/local/lib/libsqlite3.so" ; Linux, BSD, Solaris
    "/usr/pkg/lib/libsqlite3.so" ; NetBSD
    "/usr/local/lib/libsqlite3.so.13.3" ; OpenBSD 4.6
    "/usr/lib/libsqlite3.0.dylib" ; Mac OSX Darwin
    "/usr/lib64/libsqlite3.so" ; for 64Bit CentOS 6 Linux
    "/usr/lib/x86_64-linux-gnu/libsqlite3.so" ; for Ubuntu 12.04
    "/usr/lib/i386-linux-gnu/libsqlite3.so.0" ; other Linux
    "sqlite3.dll" ; Win32 DLL path and current directory
    (string (env "PROGRAMFILES") "/sqlite3/sqlite3.dll") ; Win32 SQLite3 std install
))

I believe  "sqlite3.dll" will not only work for the current directory but also for Windows standard DLL locations.



On Mac OSX, the Apple installed "/usr/lib/libsqlite3.0.dylib" will work for 32-bit and 64-bit and it also will be found by just specifying  "libsqlite3.0.dylib"  without the full path. Judging from the path-names this is not true on Linux. The expression:

Code Select Expand

(& 0x100 (sys-info -1)) ;=> 256 for 64-bit
(& 0x100 (sys-info -1)) ;=> 0 for 32-bit

could be used to find out what version of newLISP is running.

[abaddon1234]

will not only work for the current directory but also for Windows standard DLL locations.

https://www.gclub88.com/">gclub

[TedWalther]

I'm thinking we need something like a context "librarypath" set by the system init file.  And for each library to be imported, you can lookup its symbol name.  That way each distribution that packages newlisp (Debian, BSD, etc) can tune the library path for its system, without messing with the module itself.



Simple check in the module:

Code Select Expand


(if (and (context? 'librarypath) (librarypath "libgmp"))
;; THEN
  (set 'libgmp (librarypath "libgmp"))
;; ELSE
  ; do whatever we do now.
)


What the init file looks like:

Code Select Expand


;; /etc/init.lsp
;; settings for Debian Jessie (8.0)
(define librarypath:librarypath)
(librarypath "libgmp" "/usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0")