robertohuertasm / SQLite4Unity3d

SQLite made easy for Unity3d

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

how to build SQLite3.so for linux X86_64?

opened this issue · comments

Hi, i'm trying to use SQLite for my unity project and i'm just wondering how do i make the so file for desktop linux (X86_64)

tl;dr: Chances are you don't need to.

I was concerned about the same thing, so I switched to testing iBoxDB for a while which gave me easy support for Linux. After being a bit disappointed with iBox (10x slower and very fat files compared to SQLite), I came back here and took a deeper look at the Linux problem.

I don't do much lower-level programming (and when I do, it's in assembler) so I'm not much a of a "build" expert. Thus, I don't inherently know much about building libraries and what kinds of libs need to be used where. So, like you, I assumed the dlls and other libs here needed to be built special for this tool and/or Unity. Turns out, nope, the dlls here are just the standard dlls you get from sqlite.org. Furthermore, digging through the comments about Mac support, I eventually figured out there is no Mac lib here because they are relying on SQLite being built into macOS (which, looking that up, is true since OS X 10.4 -- long before the Unity 2017 rq of OS X 10.9 [if I recall correctly]).

So, it seemed a safe assumption that this tool might work with the standard SQLite lib from Ubuntu. I tested that and, yes, it works! You can even see that for yourself by grabbing the Linux version of my GRITS Racing demo from either itch.io or Steam. If the leaderboard menus are working, then SQLite is working.

Why this project doesn't just say where the libs come from up front, to help us noobs out a bit? 🤷‍♂️

Also, regarding Linux, the odds are nearly guaranteed that any Linux install that can run a Unity game already has libsqlite3-0 installed. When I tested sudo apt remove libsqlite3-0 on Linux Mint, the list of dependencies that wanted to uninstall with it obviously would have crippled the box (and it said so). Particularly of note were pulseaudio, nvidia, and ubuntu-minimal. Regardless, best practice appears to be to include such Linux libs, so I did. BTW, I did test disabling the Linux shared-library copy of libsqlite.so.* just to make sure my game's copy worked and, yes, it does.

I got libsqlite.so from here:
https://packages.ubuntu.com/bionic/libsqlite3-0
Choose whichever build you need for your platform (amd64 for x86_64, i386 for x86).

Bionic uses SQLite 3.22.0. Switch to a newer Ubuntu package if you want a newer SQLite. This project appears to be built around 3.19.3, so I felt good with 3.22.0 (and guaranteed support on Ubuntu 18.04).

Set your
image
checkboxes appropriately in Unity.


FYI, don't bother with the Win DLLs in this project either if you have a need for that OS. Get your own copies of those as well if you need them. For whatever messed-up reason (and it has been reported and not yet fixed) the dlls currently found in this project are: 64-bit 3.6.23.1 (Interop 1.0.66.0) in the x64 folder, and 64-bit 3.19.3 in the x86 folder. The x64 one is extremely old (2010 old) and the x86 one simply won't work for 32-bit.

I went with the latest Windows DLLs (3.39.1) from the source:
https://sqlite.org/download.html

If targeting Win10 and later, SQLite is built in (look for winsqlite3.dll in System32 and SysWOW64 [3.29.0 on my Win10]).

The other complexity here is whether or not "managed" DLLs will work (.NET-specific DLLs that work with Win, Linux, and Mac). I didn't test that (even though I poked at it quite a bit).

(That 3.6.23.1 dll mentioned above comes from the System.Data.SQLite project, BTW, which produces some managed DLLs... but that particular dll doesn't appear to be managed. Instead, that project appears to use a managed core DLL that then points to native DLLs. Too confusing to dig into [especially re Unity]... and I couldn't find a Linux lib from them either... well, not one from their .NET 3.5 builds.)

It would be nice to see a single managed DLL in this project... but, oh well. Someday maybe.