How to use sqlite jdbc on many different platforms?

1,325 views
Skip to first unread message

Dan F

unread,
Dec 20, 2012, 11:53:29 AM12/20/12
to xer...@googlegroups.com
Thanks for your work on the Xerial Sqlite JDBC driver. I am evaluating
using it for a project that gets shipped to consumers, i.e. on many
different platforms, some of which we are probably not anticipating.

I grabbed sqlite-jdbc-3.7.15-SNAPSHOT.jar on the website, tried it on
one of our servers, and got:

java.lang.UnsatisfiedLinkError: /tmp/sqlite-3.7.15-amd64-libsqlitejdbc.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/sqlite-3.7.15-amd64-libsqlitejdbc.so)
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.sqlite.NativeDB._open(Ljava/lang/String;I)V
        at org.sqlite.NativeDB._open(Native Method)
        at org.sqlite.DB.open(DB.java:157)
        ...

That means the .so was compiled on a system that wants 2.14.  Ours has 2.12.2.

Questions:

1. How do I rebuild the native jar on our system to use the older
libc?  Instructions at
surgery on the sqlite-jdbc-3.7.15-SNAPSHOT.jar to redo the native .so?

2. How can I be sure this issue won't arise again on systems we ship
our product on?  As I said, there are probably all sorts of platforms
configurations.  One way might be to build static libraries for each
platform, so it no longer has dependencies (other than platform
itself).  Is that possible?

3. What are the barriers to bring back the native Java client?  That
is a potential solution to #2: if the native library doesn't
initialize, fall back to pure java.  I read
Looks like "cumbersome settings" (minor?) and "not keeping up with the
latest features" (more important, but I might rather have old and
working than none).

grace

unread,
Dec 21, 2012, 10:09:12 AM12/21/12
to xer...@googlegroups.com


On Thursday, December 20, 2012 11:53:29 AM UTC-5, Dan F wrote:
Questions:

1. How do I rebuild the native jar on our system to use the older
libc?  Instructions at
surgery on the sqlite-jdbc-3.7.15-SNAPSHOT.jar to redo the native .so?

"no surgery" required.

Running make is all you need. You find the new jar in the target folder.
 
2. How can I be sure this issue won't arise again on systems we ship
our product on?  As I said, there are probably all sorts of platforms
configurations.  One way might be to build static libraries for each
platform, so it no longer has dependencies (other than platform
itself).  Is that possible?

This needs some more investigation since the shared library is built with the -static-libgcc flag.
 
3. What are the barriers to bring back the native Java client?

The decision was taken just to drop support for it rather than spend time fixing the root cause of the problem (which most likely has to do with the inner workings of NestedVM http://nestedvm.ibex.org/).
 
 That
is a potential solution to #2: if the native library doesn't
initialize, fall back to pure java.  I read
Looks like "cumbersome settings" (minor?) and "not keeping up with the
latest features" (more important, but I might rather have old and
working than none).

 You can always checkout the latest version of the code that supports building pure java. (changeset 97d4c57) 
The following commands should suffice

cd sqlite-jdbc
hg update 97d4c57
make purejava test-purejava
 

Dan F

unread,
Dec 21, 2012, 3:59:52 PM12/21/12
to xer...@googlegroups.com


On Friday, December 21, 2012 9:09:12 AM UTC-6, grace wrote:


On Thursday, December 20, 2012 11:53:29 AM UTC-5, Dan F wrote:
Questions:

1. How do I rebuild the native jar on our system to use the older
libc?  Instructions at
surgery on the sqlite-jdbc-3.7.15-SNAPSHOT.jar to redo the native .so?

"no surgery" required.

Running make is all you need. You find the new jar in the target folder.

I ran it on Ubuntu 10.04 and got it to work with the sun jdk (not openjdk at that time). (For my future reference: http://superuser.com/a/439915/56544).

How does it work that the windows and OS X libraries are put into that jar if I'm compiling on Linux? Does it pull them from somewhere, cross-compile, or hidden option c?
 
 
2. How can I be sure this issue won't arise again on systems we ship
our product on?  As I said, there are probably all sorts of platforms
configurations.  One way might be to build static libraries for each
platform, so it no longer has dependencies (other than platform
itself).  Is that possible?

This needs some more investigation since the shared library is built with the -static-libgcc flag.

I will try removing the -shared flag if my testing shows we want to proceed. I will report back if I learn anything.

Thanks for your help.

grace

unread,
Dec 22, 2012, 10:39:34 PM12/22/12
to xer...@googlegroups.com


On Friday, December 21, 2012 3:59:52 PM UTC-5, Dan F wrote:


On Friday, December 21, 2012 9:09:12 AM UTC-6, grace wrote:


On Thursday, December 20, 2012 11:53:29 AM UTC-5, Dan F wrote:
Questions:

1. How do I rebuild the native jar on our system to use the older
libc?  Instructions at
surgery on the sqlite-jdbc-3.7.15-SNAPSHOT.jar to redo the native .so?

"no surgery" required.

Running make is all you need. You find the new jar in the target folder.

I ran it on Ubuntu 10.04 and got it to work with the sun jdk (not openjdk at that time). (For my future reference: http://superuser.com/a/439915/56544).

How does it work that the windows and OS X libraries are put into that jar if I'm compiling on Linux? Does it pull them from somewhere, cross-compile, or hidden option c?
 
It pulls them from src/main/resources/org/sqlite/native/{Mac,Windows}.
The package goal for maven takes care of this.
 
 
2. How can I be sure this issue won't arise again on systems we ship
our product on?  As I said, there are probably all sorts of platforms
configurations.  One way might be to build static libraries for each
platform, so it no longer has dependencies (other than platform
itself).  Is that possible?

This needs some more investigation since the shared library is built with the -static-libgcc flag.

I will try removing the -shared flag if my testing shows we want to proceed. I will report back if I learn anything.

The -shared flag is so that, you build an sqlite shared library and not an executable. 

Thanks for your help.

Dan F

unread,
Dec 28, 2012, 2:06:31 PM12/28/12
to xer...@googlegroups.com
FYI, I found out more about this message.

There is a change to memcpy with overlapping regions (which is undefined behavior by the standard). See http://www.sourceware.org/bugzilla/show_bug.cgi?id=12518. They decided to make memcpy have a new behavior in 2.14 with a new symbol memcpy@@GLIBC_2.14.

So if one links against the old memcpy, then as long as no one specifies overlapping regions (which has undefined behavior), everything works. Building with the new memcpy symbol of course requires it in libc.

On Thursday, December 20, 2012 10:53:29 AM UTC-6, Dan F wrote:
 
I grabbed sqlite-jdbc-3.7.15-SNAPSHOT.jar on the website, tried it onone of our servers, and got:
Reply all
Reply to author
Forward
0 new messages