SQLite Forum

SQLite 3.34 binary not working on Ubuntu 20.04 (not found)

SQLite 3.34 binary not working on Ubuntu 20.04 (not found)

(1) By Holger J (holgerj) on 2020-12-04 10:51:04 [link]

After downloading and unpacking sqlite-tools-linux-x86-3340000.zip I find the following behaviour:

hj@tuxedo:/usr/local/bin$ ls -l sqlite3
-rwxrwxr-x 1 root hj 1014308 2020-12-04 11:25 sqlite3
hj@tuxedo:/usr/local/bin$ ./sqlite3
bash: ./sqlite3: No such file or directory
hj@tuxedo:/usr/local/bin$ md5sum sqlite3
7f85edb0fc9c302c7d0e543b5eda1654  sqlite3
hj@tuxedo:/usr/local/bin$ ldd sqlite3
	not a dynamic executable

Downloading the autoconf-sources, configure, make produces executable sqlite3.

(2) By Richard Hipp (drh) on 2020-12-04 14:40:01 in reply to 1 [link]

A new copy of [sqlite-tools-linux-x86-3340000.zip][1] has been uploaded to
the [download page][2].  The new version statically links against [zlib][3].
Please try out the next version and report back if you continue to have

[1]: https://sqlite.org/2020/sqlite-tools-linux-x86-3340000.zip
[2]: https://sqlite.org/download.html
[3]: https://zlib.net

zLib is probably the only library that is in more widespread use than
SQLite.  Odd that Ubuntu would not have it installed by default....

(3) By Holger J (holgerj) on 2020-12-05 17:42:20 in reply to 2 [link]

Sorry, but no. The behaviour is the same. 

The message doesn't complain about a missing library, even the previous executable was statically linked. It complained that the executable itself wasn't there, although ls and md5sum clearly proved that it existed.

And of course Ubuntu has zlib installed (not the source/dev version, of course), because many programs need it.

(4) By Dan Kennedy (dan) on 2020-12-05 19:58:50 in reply to 3 [link]

It's a 32-bit x86 binary. Can you run any 32-bit binaries on this machine (older versions of the shell tool from sqlite.org, for example)?

Apparently the default install of Ubuntu 20.04 does support these, but I imagine it's possible to install it without it.

(5) By anonymous on 2020-12-05 20:03:01 in reply to 1 [link]

When a statically-linked executable returns "no such file or directory" upon execution, it could mean multiple things. Typically, ELFs with missing dependencies result in error messages from the linker containing `cannot open shared object file`, not _only_ `No such file or directory`.

What you have looks more like missing ELF loader (e.g. `/lib64/ld-linux-x86-64.so.2` on my system, which is the binary that's supposed to load dynamically linked executables and their `.so` dependencies). This may happen on purely 64-bit systems when trying to run a 32-bit executable wanting a 32-bit loader. What does `readelf -e ./sqlite3 | grep interpreter` show for both executables?

(6) By Larry Brasfield (LarryBrasfield) on 2020-12-05 20:31:00 in reply to 3 [link]

In what directory did you put the latest sqlite3 executable?

Does that directory appear when, in bash, you enter:<code>
  echo $PATH

Here are commands entered (to bash) in a Ubuntu 20 session just now:<code>
  sudo apt install gcc
  sudo apt install automake
  sudo apt install make
  cd sqlite-autoconf-3340000/
  sudo mv sqlite3 /usr/bin/
  which sqlite3
</code>, which (after omitting much install and build verbosity) yields:<code>
SQLite version 3.34.0 2020-12-01 16:14:00
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

I had to build because the 32-bit executable for Linux cannot be run on my 64-bit system, at least not conveniently.

(7) By Holger J (holgerj) on 2020-12-06 16:37:31 in reply to 4

Yes, now I checked and found

$ file sqlite3
sqlite3: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 4.3.0, stripped

I wonder why

  *  a 32 bit executable is provided as *the* Linux version, while most distributions aren't even available in 32 bit versions,
  *  why the system doesn't give a proper message saying that a 32 bit executable cannot be run on the current system.

(8) By Holger J (holgerj) on 2020-12-06 16:39:14 in reply to 6 [link]

Since I tried to start it with ./sqlite3 the directory doesn't matter, as long as it is the current one.

And yes, the problem was 32 bit - see my answer above.

(9) By Holger J (holgerj) on 2020-12-06 16:41:32 in reply to 5 [link]

Yes, the file /lib/ld-linux.so.2 isn't present on my system.

I still wonder why the message said that sqlite3 was missing instead of /lib/ld-linux.so.2 was missing.

Of course that's nothing sqlite3 can do about.

But there should be a **very clear hint** on the downloads page that it is a 32 bit version, because that's nothing anybody would expect nowadays.

And if there were two versions - 32 and 64 bit - that would be ideal.

(10) By Larry Brasfield (LarryBrasfield) on 2020-12-06 17:04:49 in reply to 7 [link]

On my very recent version of Ubuntu 20, attempting to execute that 32-bit image from bash produces:<code>
  cannot execute binary file: Exec format error
</code>, which is clearly different from the "not found" in your thread title, and from the "No such file or directory" in your post #1, and from "Sorry, but no. The behaviour is the same." in your post #3.

If you want effective and efficient help here (or any other forum), you need to be accurate with your reports of the problem symptoms and context.

As for why the SQLite devs publish a 32-bit image, Ubuntu has only recently stopped offering 32-bit builds, as of the v20 release.

As for why "the system doesn't give a proper message saying that a 32 bit executable cannot be run on the current system.", you would have to ask in a Linux forum. In my opinion, the message I quoted above is a proper message indicating that the "binary file" does not have a format known to the loader. I think it would be beyond the call of duty, once that determination is made, for it to examine the file attempting to guess what it is and educate the user. After all, there is the wonderful 'file' program that knows how to do that. The loader's complaint is surely enough to trigger the error-instigator's question, "Well then, what is that binary file?". Maybe the loader's author's can be persuaded to add something like a tip referring to the 'file' program. (But that is not generally the *Nix way.)

(11) By Larry Brasfield (LarryBrasfield) on 2020-12-06 20:12:51 in reply to 9 [link]

>  there should be a very clear hint ...

For future reference: In the archive filename, "sqlite-tools-linux-x86-3340000.zip", the '-x86-' means it is for 32-bit Intel CPUs such as i486, i586, (or i386 if you have one.)

Of course, that may be too subtle a hint for some, although this naming convention has been widely adopted.

>  if there were two versions - 32 and 64 bit - that would be ideal.

It would be more convenient for some. And I would agree that, these days, a 64-bit image (aka '...amd64...') would be more useful than the 32-bit one. But I have always seen provision of prebuilt executables as a convenience rather than cause to be making a bunch of "should" pronouncements regarding the gajillion architectures for which no prebuilt images are provided.