I've tested it on CentOS 7. It gives exactly the same output running "configure && make && make install" but made a different library. The shared library exports sqlite3_errstr now, but it fails to open an sqlite database created on another machine with error "database disk image is malformed".

Is it a known problem? Does sqlite configure script works differently on older distributive?

This is not a problem that we have ever seen before. Nor do we have a CentOS 6 machine on which to try to repro it. The sqlite3_errstr() interface should not be affected by configuration changes.

Are you compiling from canonical sources, or are you using the tarball that contains the pre-built amalgamations?

I've found no clues to offer, but I do have some relevant information and a surmise that may aid your investigation of your problem.

The API, "const char *sqlite3_errstr(int)", is treated exactly as is the API, "const char *sqlite3_errmsg(sqlite3*)", by the SQLite build system. The former is much newer than the latter.

From these facts, I conclude that the problem as you describe it cannot happen. I suspect and surmise that what you call the "resulting shared library" is not, in fact, a result produced by the build from 3.38.0 sources.

As to how the discrepancy arises, between what you think you built and what you have observed exported symbols in, my guesses are: The build product did not land where you think it should have; it may have landed elsewhere or the copy operation to put it there may have failed, perhaps silently for some strange reason.

I would suggest that you build from canonical sources, obtained from sqlite.org, into a clean directory, with a merely local (rather than "installed") result. Do your symbol check on that. If that is awry, there will be great interest in discovering why and getting that fixed. If that is fine, with all 3.38.0 APIs properly exposed, then you have a more locally relevant investigation to do.

I can reproduce this on a CentOS 6 VM by:

1. Cloning the GitHub mirror of the SQLite sources and building as you say.

2. Not installing the resulting library.

3. Attempting to build a trivial program to call the API in question.

   Key line of code: puts(sqlite3_errstr(SQLITE_OK));

This happens because when you build this way, you get a libtool library as output that isn't fully prepared to be linked against without using libtool. Not only is it not in the default library search path, it isn't in the OS's shared library cache, etc. Fixing all this up is part of what installing does.

You can get the test program to build with:

  $ libtool --mode=link gcc foo.o -lsqlite3 -o foo

That works because it looks at sqlite3.la in the build directory, which tells libtool how to locate the just-built copy of SQLite as opposed to the one that ships with the OS, which doesn't have that API, since it was added in 2012, but the OS ships a version of SQLite from 2009.

Side issue 1: Why are you still using an OS that stopped getting updates years ago?

Side issue 2: Why are you trying to build new software — evidenced by your need for SQLite 3.38.0 — atop that ancient foundation?

Oh.. Thanks! I just wants to make a compatible binary that can run on any linux machine. You need to compile it using an old glibc then. Travis just recently switched to CentOS 7 build environment for AppImage. I will use an older sqlite version, 3.38.0 is just the first version I tried.

a compatible binary that can run on any linux machine

Then I suggest that you add sqlite3.c to your program's list of modules so it's statically linked to your binary.

I will use an older sqlite version

Bad plan. That gets you old bugs, long since squished.

The only other option I could reasonably suggest would be to link against the ancient platform version of SQLite (3.6.20) on the theory that it is "stable." That means you give up on sqlite3_errstr() and every other improvement made to SQLite in the past 13 years.