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.

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

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

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.

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?

In what directory did you put the latest sqlite3 executable?

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

Here are commands entered (to bash) in a Ubuntu 20 session just now: sudo apt install gcc sudo apt install automake sudo apt install make cd sqlite-autoconf-3340000/ ./configure make sudo mv sqlite3 /usr/bin/ which sqlite3 sqlite3 , which (after omitting much install and build verbosity) yields: 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. sqlite>

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

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.

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.

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.

On my very recent version of Ubuntu 20, attempting to execute that 32-bit image from bash produces: cannot execute binary file: Exec format error , 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.)

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.

There is a far simpler solution than compiling the source code. Just install libraries for executing 32bit ELF files. In ubuntu 18, and 22, for example, this command works:

sudo apt-get install lib32z1