search

sgilbertson / sqlite4java

Automatically exported from code.google.com/p/sqlite4java
0 stars 0 forks source link

Mac version never loads of JNI library fat binary because 10.4 version preceeds x86_64 version #50

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It seems that the code that searches for the JNI library always includes the 
architecture in the name string, thus it will always search for 
sqlite4java-osx-x86_64.jnilib or sqlite4java-osx-i386.jnilib, and will never 
match to the fat binary. On my (x86_64) machine this code always ends up using 
sqlite4java-osx-10.4.jnilib, which doesn't seem ideal.

I would suggest adding the following to collectBaseLibraryNames:
if ("osx".equals(os)) {
      r.add(base);
}

Original issue reported on code.google.com by patrickk...@gmail.com on 12 Dec 2012 at 6:28

GoogleCodeExporter commented 9 years ago 
But it does check base name - see collectBaseLibraryNames just two lines 
further. Please try running this: 
   java -jar sqlite4java.jar -d
to make it try to load all variants of the binary and output the results.

Original comment by ser...@gmail.com on 12 Dec 2012 at 8:26

GoogleCodeExporter commented 9 years ago 
You're right, it does, but in this case it's after the check for -10.4, which 
causes it to match to -10.4 rather than the fat binary. r.add(base) should be 
moved up a few lines.

java -jar sqlite4java.jar -d
sqlite4java 282
121212:134119.239 FINE [sqlite] Internal: loading library
121212:134119.239 FINE [sqlite] Internal: 
java.library.path=/Users/XXXXX/Library/Java/Extensions:/Library/Java/Extensions:
/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
121212:134119.240 FINE [sqlite] Internal: sqlite4java.library.path=null
121212:134119.240 FINE [sqlite] Internal: cwd=XXXXX
121212:134119.240 FINE [sqlite] Internal: default path=XXXXX
121212:134119.240 FINE [sqlite] Internal: forced path=null 
121212:134119.240 FINE [sqlite] Internal: os.name=mac os x; os=osx
121212:134119.240 FINE [sqlite] Internal: os.arch=x86_64
121212:134119.240 FINE [sqlite] Internal: trying to load sqlite4java-osx-x86_64
121212:134119.243 FINE [sqlite] Internal: cannot load sqlite4java-osx-x86_64: 
java.lang.UnsatisfiedLinkError: no sqlite4java-osx-x86_64 in java.library.path
121212:134119.243 FINE [sqlite] Internal: trying to load sqlite4java-osx-amd64
121212:134119.244 FINE [sqlite] Internal: cannot load sqlite4java-osx-amd64: 
java.lang.UnsatisfiedLinkError: no sqlite4java-osx-amd64 in java.library.path
121212:134119.244 FINE [sqlite] Internal: trying to load sqlite4java-osx-10.4
121212:134119.249 INFO [sqlite] Internal: loaded sqlite4java-osx-10.4 from 
system path
121212:134119.252 INFO [sqlite] Internal: loaded sqlite 3.7.10, wrapper 0.2
SQLite 3.7.10
Compile-time options: ENABLE_COLUMN_METADATA ENABLE_FTS3 
ENABLE_FTS3_PARENTHESIS ENABLE_LOCKING_STYLE=0 ENABLE_MEMORY_MANAGEMENT 
ENABLE_RTREE OMIT_DEPRECATED TEMP_STORE=1 THREADSAFE=1

Original comment by patrickk...@gmail.com on 12 Dec 2012 at 9:44

GoogleCodeExporter commented 9 years ago 
The files are tried in the order of more specific to less specific. So the 
order is correct. 

The problem is that there's no more specific binary - so we might need to 
rename libsqlite4java-osx.jnilib to libsqlite4java-osx-amd64.jnilib.

The workaround in your case is to do that manually - rename the file, or remove 
10.4 binary.

Original comment by ser...@gmail.com on 14 Dec 2012 at 10:18

GoogleCodeExporter commented 9 years ago

Original comment by evj...@almworks.com on 29 Oct 2014 at 10:46