First, the dylib should be called libsqlite3.3.49.0.dylib, not libsqlite3.dylib.3.49.0. Then somehow the name and symlinks are created incorrectly. They should be

(After several minutes attempting to decipher your Makefile.in, which does not match the canonical one, it's finally clear that you're using the "autoconf" bundle. In future reports, please state which source it is you're building from.)

First, the dylib should be called libsqlite3.3.49.0.dylib, not libsqlite3.dylib.3.49.0.

That's a Mac-ism. The convention for those symlinks on other Unix-like OSes matches the part which your patch removes. libtool, which was used in the autoconf bundle until this release, hid such mysteries from us. Another example of such libtool voodoo is...

Apparently, the dylib version is not set.

We very specifically do not have any highly-platform-specific flags like the Mac-specific "-current_version". That sort of voodoo was previously done "under the table" by libtool.

We'll look at adapting the makefile (macfile?) to make it work in that environment for the next release. Autosetup will let us replace blocks depending on configuration options (like the OS), but the pieces which you've patched works as-is (and as intended) on other Unix-esque OSes.

It turns out that we use both the autoconf tarball (for sqlite3 itself) and sqlite-src tarball (for the sqlite3-tcl and sqlite3-tools sub-ports).

I'll try to remember to add that tidbit in the future!

I just updated the MacPorts Portfile for sqlite3 to version 3.49.0.

i'm reworking the makefile to account for the reported macisms but need your help understanding how this part gets you your desired results:

-libsqlite3.SO = libsqlite3$(T.dll)
+libsqlite3.SO = libsqlite3

 $(libsqlite3.SO): sqlite3.o
 	$(CC) -o $@  sqlite3.o $(LDFLAGS.shlib) \
...

(Noting that i don't have access to a machine to try that out on.)

The result of -o $@ would be libsqlite3. It "should" be libsqlite3.dylib, which is what it resolves to if the top-most change of that snippet is not applied.

If the intention of that change was for the sake of the install rules then i understand why it was done, but i don't understand how it can possibly build the library properly with that change.

Edit:

-current_version 9.7.0 -compatibility_version 9.0.0

Where do those numbers come from? Do they need to be configurable or can they be hard-coded with those values?

I don't know where these numbers initially came from, but I'm assuming the build system for the previous versions set them automatically. I certainly did not add them on my end!

I don't know where these numbers initially came from, but I'm assuming the build system for the previous versions set them automatically. I certainly did not add them on my end!

We never assigned those values and it's likely that neither has changed since the project's earliest days. Similarly, the legacy build on non-Mac Unices has applied the static libtool-defined value 0.8.6 to the DLLs since the times of our ancestors.

i'm going to hard-code the values 9.0.0 and 9.6.0 (not 9.7.0, as we have never bumped any values which libtool applied) until/unless it turns out they need to be configurable.

For completeness's sake, this is what libtool from the 3.47 tree says on the topic:

        darwin)
          # Like Linux, but with the current version available in
          # verstring for coding it into the library header
          func_arith $current - $age
          major=.$func_arith_result
          versuffix="$major.$age.$revision"
          # Darwin ld doesn't like 0 for these options...
          func_arith $current + 1
          minor_current=$func_arith_result
          xlcverstring="${wl}-compatibility_version ${wl}$minor_current ${wl}-current_version ${wl}$minor_current.$revision"
          verstring="-compatibility_version $minor_current -current_version $minor_current.$revision"
          ;;

Whatever that means 🤷. They're not version number this project has assigned, in any case.

Of course they are version numbers your project assigned. It's right there on line 5 of your Makefile.am (in sqlite3 3.48.0; of course in 3.49.0 this file was removed):

libsqlite3_la_LDFLAGS = -no-undefined -version-info 8:6:8

How specifically the version-info of 8:6:8 gets transformed to platform-specific versioning information like 9.6.0 on macOS is something you Do Not Need To Know unless you elect to remove libtool; if you do, then of course if becomes your responsibility to continue your library's version numbers correctly, taking into account all of the platform differences that libtool was handling for you.

How to update libtool version-info as your library evolves is described at https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html. If your project hasn't been doing that all along, that's unfortunate.

I'm completely floored that a mature project like sqlite would rip out the part of its build system that was using libtool, which arranged for libraries to be created properly on a variety of systems, without even understanding how it works or what it was doing for you, and releasing a completely broken sqlite build system (as far as macOS is concerned) as a result.

I'm sorry that our foibles annoy you. Perhaps you could help us fix the problem, now? And, no, reverting to libtools is not a "fix".

Please remember that if the SQLite devs were the kind of people who did things the way everybody else does them, then SQLite would have never been created. There is good and bad in this. On the plus side, you get a small, fast, reliable, full-function, embedded SQL database with complete sources, in the public domain. The minus side is that the build system sometimes brakes when you try to use it in a way that the devs never thought to use it themselves and hence have no test cases for.

Your assistance in fixing the recent build issues will be appreciated.

-current_version 9.7.0 -compatibility_version 9.0.0

Before i check these changes in, can you please confirm that it still builds properly if that is changed to:

 -Wl,-current_version 9.6.0 -Wl,-compatibility_version 9.0.0

The reason for 9.6.0 is explained in a prior response. The -Wl, prefix is derived from decrypting libtool and means "these are flags for the linker." That it works for you without that -Wl, prefix surprises me.

After building I got an error that...

There is a snapshot build at:

https://wasm-testing.sqlite.org/tmp/sqlite-snapshot-202502070201.tar.gz

Edit: https://wasm-testing.sqlite.org/tmp/sqlite-snapshot-202502071051.tar.gz (this one uses a proper feature check for the linker flags)

That tarball is equivalent to the autoconf bundle but (A) contains what i believe to be fixes for your reported problems and (B) has a version of 3.50.0, so you won't want to do a release based on that.

Specifically:

• (Only) on platforms where the DLL extension is ".dylib" the installation works like your patch.
• (Only) on platforms which the configure script believes are Mac, -..._version flags are added when creating libsqlite3.dylib, but those flags are prefixed with -Wl, because i believe that is "more correct."

Please try it out and let us know whether it resolves the problems. If it does it will be applied to the 3.49 branch.

That tarball will be deleted in a day or so.

Setting up libsqlite3.dylib version symlinks...

i'm assuming those look correct to you. There was a definite possibility of a typo on my part in the symlink names.

There is nothing wrong with keeping the current version @ 9.6.0,

After having looked more into that: i can find no evidence that this project has ever explicitly set or changed the 9.0.0 and 9.6.0. Presumably they're for specifying binary compatibility, which is something this project never breaks, making them effectively irrelevant except that changing them breaks dynamic linking of existing applications which linked to legacy builds with those values set.

If you'll replace the following files from your 3.49 source bundle with the same-named files from that snapshot, you'll have a 3.49.0 release which will build on your platform:

• auto.def
• Makefile.in
• autosetup/sqlite-config.tcl

(The other files which changed in this branch aren't relevant to that specific build.)

That should be all there is to it. i'll get these fixes merged into the trunk and 3.49 branches sometime today.

Thank you for the report and build feedback!

The MacPorts sqlite3 Portfile has been updated to version 3.49.0. Thanks for your help!

The MacPorts sqlite3 Portfile has been updated to version 3.49.0. Thanks for your help!

FYI: this evening (CET) we got an off-list report which prompted one additional patch for the "make install" rules on mac platforms.

That issue would not affect the MacPorts install, as we first deactivate (uninstall) the previously active version before activating (installing from the pre-built archive) the new version.

No, it can't be set using DYLD_LIBRARY_PATH. It can be set using the -install_name linker flag.

otool should have given the full path for libsqlite3.dylib, i.e. /opt/local/lib/libsqlite3.dylib

The word "otool" is nowhere to be found in our source tree (which includes all of the build files):

[stephan@nuc:~/f/s/lite]$ find . -type f -exec grep -w otool \{} \;
<no output>

(Try that without the -w and you'll get tons of references to "autotools".)

i.e. that call is not coming from us.

Our build files cannot conceivable target every oddball environment nor address the quirks of every oddball tool. The sqlite amalgamation (which is what ships in the distribution you're using) is trivial to build with custom makefiles, and we encourage folks whose environments have "special needs" to account for those special needs in their own build files.

otool is the Darwin/macOS object file displaying tool. It is part of the OS.

My point is: our build tools do not refer to otool anywhere, so any invocation of it you're seeing is not from us. To be clear, that's in reference to:

Unfortunately, I just ran into another problem: otool should ...

If your platform needs otool, you'll need to invoke it yourself from your own (or patched) build files.

For non-Windows platforms we provide the "lowest common denominator" of builds, which boils down to widespread Unix conventions: make, cc, ld, ar, install, core binaries always found under /bin, and those tools we embed directly in the source tree. Any exotic tooling beyond that (e.g. otool) is currently out of scope for our deliverables as well as out of scope for our development and testing capacity.

otool is the only way to tell how a .dylib library has been linked. It is not used in the build process. I used it to diagnose why we had a broken install.

It is not used in the build process. I used it to diagnose why we had a broken install.

Ah, my apologies. i misunderstood:

Unfortunately, I just ran into another problem: otool should ...

As being a bug report!