事实证明，这个过程超麻烦（如常日一样），但是非常有趣！
-- Julia Evans（作者）
上周，我一贯在做一个 SQL 网站（ https://sql-steps.wizardzines.com/ ，一个 SQL 示例列表）。我利用 sqlite 运行网站上的所有查询，并且我想在个中一个例子（ 这个 ）中利用窗口函数。
但是我利用的是 Ubuntu 18.04 中的 sqlite 版本，它太旧了，不支持窗口函数。以是我须要升级 sqlite！
事实证明，这个过程超麻烦（如常日一样），但是非常有趣！
我想起了一些有关可实行文件和共享库如何事情的信息，结论令人满意。以是我想在这里写下来。
（剧透： https://www.sqlite.org/howtocompile.html 中阐明了如何编译 SQLite，它只需花费 5 秒旁边，这比我平时从源码编译的体验随意马虎了许多。）
考试测验 1：从它的网站下载 SQLite 二进制文件SQLite 的下载页面 有一个用于 Linux 的 SQLite 命令行工具的二进制文件的链接。我下载了它，它可以在条记本电脑上运行，我以为这就完成了。
但是后来我考试测验在构建做事器（Netlify） 上运行它，得到了这个极其奇怪的缺点：“File not found”。我进行了追踪，并确定 execve 返回缺点代码 ENOENT，这意味着 “File not found”。这有点令人发狂，由于该文件确实存在，并且有精确的权限。
我搜索了这个问题（通过搜索 “execve enoen”），找到了 这个 stackoverflow 中的答案 ，它指出要运行二进制文件，你不仅须要二进制文件存在！
你还须要它的加载程序才能存在。（加载程序的路径在二进制文件内部）
要查看加载程序的路径，可以利用 ldd，如下所示：
$ ldd sqlite3 linux-gate.so.1 (0xf7f9d000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7f70000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7e6e000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7e4f000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7c73000) /lib/ld-linux.so.2
以是 /lib/ld-linux.so.2 是加载程序，而该文件在构建做事器上不存在，可能是由于 Xenial（Xenial 是 Ubuntu 16.04，本文该当利用的是 18.04 “Bionic Beaver”）安装程序不支持 32 位二进制文件（？），因此我须要考试测验一些不同的东西。
考试测验 2：安装 Debian sqlite3 软件包好吧，我想我也容许以安装来自 debian testing 的 sqlite 软件包 。考试测验从另一个我不该用的 Debian 版本安装软件包并不是一个好主张，但是出于某种缘故原由，我还是决定考试测验一下。
这次绝不料外地毁坏了我打算机上的 sqlite（这也毁坏了 git），但我设法通过 sudo dpkg --purge --force-all libsqlite3-0 规复了，并使所有依赖于 sqlite 的软件再次事情。
考试测验 3：提取 Debian sqlite3 软件包我还考试测验仅从 Debian sqlite 软件包中提取 sqlite3 二进制文件并运行它。绝不料外，这也行不通，但这个更随意马虎理解：我有旧版本的 libreadline（.so.7），但它须要 .so.8。
$ ./usr/bin/sqlite3./usr/bin/sqlite3: error while loading shared libraries: libreadline.so.8: cannot open shared object file: No such file or directory考试测验 4：从源代码进行编译
我花费这么多韶光考试测验下载 sqlite 二进制的缘故原由是我认为从源代码编译 sqlite 既烦人又耗时。但是显然，下载随便一个 sqlite 二进制文件根本不适宜我，因此我终极决定考试测验自己编译它。
这有辅导： 如何编译 SQLite 。它是宇宙中最大略的东西。常日，编译的觉得是类似这样的：
运行 ./configure意识到我短缺依赖再次运行 ./configure运行 make编译失落败，由于我安装了缺点版本的依赖去做其他事，之后找到二进制文件编译 SQLite 的办法如下：
从下载页面下载整合的 tarball运行 gcc shell.c sqlite3.c -lpthread -ldl完成！！
！
所有代码都在一个文件（sqlite.c）中，并且没有奇怪的依赖项！
太奇妙了。
对我而言，我实际上并不须要线程支持或 readline 支持，因此我用编译页面上的解释来创建了一个非常大略的二进制文件，它仅利用了 libc 而没有其他共享库。
$ ldd sqlite3 linux-vdso.so.1 (0x00007ffe8e7e9000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbea4988000) /lib64/ld-linux-x86-64.so.2 (0x00007fbea4d79000)这很好，由于它使体验 sqlite 变得随意马虎
我认为 SQLite 的构建过程如此大略很酷，由于过去我很乐于 编辑 sqlite 的源码 来理解其 B 树的实现办法。
鉴于我对 SQLite 的理解，这并不令人感到意外（它在受限环境/嵌入式中确实可以很好地事情，因此可以以一种非常大略/最小的办法进行编译是故意义的）。 但这真是太好了！
via: https://jvns.ca/blog/2019/10/28/sqlite-is-really-easy-to-compile/
作者： Julia Evans 选题： lujun9972 译者： geekpi 校正： wxy
本文由 LCTT 原创编译， Linux中国 名誉推出
点击“理解更多”可访问文内链接
