FreeBSD amd64 native code is ignored when FreeBSD x86_64 detected

[timmc]

When I try to use version 3.8.11.2 on 64-bit FreeBSD, I get the following error: No native library is found for os.name=FreeBSD and os.arch=x86_64. However, if I copy org/sqlite/native/FreeBSD/amd64/libsqlitejdbc.so to org/sqlite/native/FreeBSD/x86_64/libsqlitejdbc.so and repack the jar file, the library works.

I'd be happy to submit a PR that duplicates that binary to both paths, but I suspect the right answer is something in OSInfo.java, as noted in https://bitbucket.org/xerial/sqlite-jdbc/issues/206/native-lib-for-freebsd-cant-be-resolved.

[timmc]

If anyone else needs a quick workaround, you may find this new addition to my build script useful -- it extracts the native library and repacks it under the other path. I'm sure there's a much better way to write this, but it gets the job done:

bsd=org/sqlite/native/FreeBSD
jar_path=relative/path/to.jar
rm -rf build/repack
mkdir -p build/repack
unzip -qo $jar_path $bsd/amd64/libsqlitejdbc.so -d build/repack
mkdir -p build/repack/$bsd/x86_64
mv build/repack/$bsd/amd64/libsqlitejdbc.so build/repack/$bsd/x86_64/
rmdir build/repack/$bsd/amd64
(cd build/repack/; zip -q -r --move --grow ../../$jar_path *)

[sudoqux]

I've encountered this error as well (FreeBSD, x86_64, sqlite-jdbc 3.8.11.2).

Observations

The OSInfo class keeps an "archMapping" map which, among others, maps key "x86_64" to value "x86_64". This is used for determining the native folder path, in OSInfo.getNativeLibFolderPathForCurrentOS().

The method getNativeLibFolderPathForCurrentOS builds the path based on a translated OS name and architecture, using predefined mappings. For OS and architechture "FreeBSD" + "x86_64", the resulting path ends up being: "FreeBSD/x86_64". The OSInfo class is used by the SQLiteJDBCLoader class, which prepends "/org/sqlite/native/" to the result of calling getNativeLibFolderPathForCurrentOS.

When looking at the source folder structure, the "Linux", "Mac" and "Windows" folders all have a subfolder named "x86_64". The FreeBSD folder does not have a subfolder named "x86_64", it only has a folder named "amd64".

The previously mentioned map in OSInfo, also has a mapping for the architecture key "amd64", to value "x86_64".

Possible solution?

I suspect this commit (May 7th, 2015) is the source of the error: 6b46954

The title is "Improved folder handling, And add a workaround when failed to resolve..." and it adds the archMapping map to OSInfo, along with renaming:
Linux/amd64/libsqlitejdbc.so -> Linux/x86_64/libsqlitejdbc.so
Windows/amd64/sqlitejdbc.dll -> Windows/x86_64/sqlitejdbc.dll

Notice how the native libraries are moved from the "amd64" to the "x86_64" folder, and especially notice how there is no rename for the FreeBSD library, which still resides in the "amd64" subfolder. It appears the "old" OSInfo mapped architectures, which for some would end in an "amd64" subfolder.

I believe a simple rename will solve the issue, assuming all FreeBSD architectures mapped to "x86_64", can use the native library in "amd64".
The rename would be:
FreeBSD/amd64/libsqlitejdbc.so -> FreeBSD/x86_64/libsqlitejdbc.so

As verified by timmc, this works when repacking the jar. I successfully did so as well.

[jan0sch]

I can confirm the bug and the workaround and have create a pull request that could solve the issue by simply providing the binary under both paths.