Would it be possible to provide backwards compatibility for LDFLAGS as well?

Its lack of customization is intentional. What specific problem are you trying to solve which requires linking in libraries which the code doesn't use (and therefore won't import symbols for at link-time)?

Mainly that it can be used to enable static linking of dependent libraries and other such useful linker flags.

I have a feeling this issue might also be affecting MacOS build and ability to set up backward compatibility, though I'm not exactly certain why.

I came across a post stating that:

This is what worked for me to compile for x86_64/arm64 and to support older mac OS versions:

export MACOSX_DEPLOYMENT_TARGET=10.13
export LDFLAGS="-Wl,-macosx_version_min,10.13"
export CFLAGS="-mmacosx-version-min=10.13 -arch x86_64 -arch arm64 -Os -DQSLITE_DQS=0"
./configure --enable-threadsafe
make
make install

If the build system is deliberately blocking the setting of LDFLAGS that could affect the MacOS builds.

Typically, you can set the MIN OS version and the SDK using the following environment variables (an example):

export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk
export MACOSX_DEPLOYMENT_TARGET=11.0

This used to work in 3.46.1 but now no longer does in 3.47. Downstream bug report: https://trac.macports.org/ticket/71174

On trunk with autosetup the behavior for CFLAGS has been preserved, but LDFLAGS no longer works.

After re-examining the legacy build, the capability of passing LDFLAGS to the configure script (but not to make) has been reinstated in the current trunk, with the following notes:

• The legacy build applies such LDFLAGS to all link operations for all deliverables (more than a dozen of them). Frankly, that makes me queasy.

• The 3.48+ build applies them (as of this writing) more selectively. Search main.mk for LDFLAGS.configure to see where they're set. In short, it applies to any binaries or libraries which directly link in the library's core source/object files or libsqlite3.a.

FWIW, the new behavior more or less matches your proposed patch, but accounts for the LDFLAGS not being overridable from a make invocation, in order to emulate the historical build's policy.

To address Lukas' points:

If the build system is deliberately blocking the setting of LDFLAGS that could affect the MacOS builds.

We know that the canonical build process in the trunk works on MacOS systems which team members, and at least a couple of forum-goers, have tested on. What the new build will break is...

Typically, you can set the MIN OS version and the SDK using the following environment variables (an example):

The MACOSX_DEPLOYMENT_TARGET handling is a libtool'ism and libtool, being part of the Autotools, is no longer part of the build process. We were unaware, until your post, that libtool performs that particular voodoo behind the scenes and have no plans to reimplement that, nor any number of other libtool'isms or highly-platform-specific tricks, in the new build.

Builds which rely on esoteric Autotool'isms or highly-platform-specific treatment will need to search for alternative solutions. For example...

For someone comfortable with maintaining the GNU Autotools, it would be a small matter to create a custom build which does nothing more than import (sqlite3.c, sqlite3.h, shell.c) from the canonical build process then uses libtool to build them. That is, however, out of scope for this project.

This used to work in 3.46.1 but now no longer does in 3.47.

Are you certain it's 3.47 and not the trunk (a.k.a. 3.48)? 3.47 uses the exact same build process as 3.46.x, with the addition of some TCL-specific handling which has no effect on the LDFLAGS or libtool.

The latest on trunk works perfectly. Thank you!

The legacy build applies such LDFLAGS to all link operations for all deliverables (more than a dozen of them). Frankly, that makes me queasy.

But it is expected to be applied to all outputs.

• On OpenBSD, /usr/local/lib is not part of the default search, so being able to ./configure LDFLAGS=-L/usr/local/lib is desired. Another instance is Solaris-like OSes where convenient extras land in e.g. /opt/ooce/lib/amd64.
• When you choose another ABI using the same host compiler (rather than a dedicated cross compiler), then e.g. ./configure CFLAGS=-m32 LDFLAGS=-m32 is required.

When you choose another ABI using the same host compiler (rather than a dedicated cross compiler), then e.g. ./configure CFLAGS=-m32 LDFLAGS=-m32 is required.

That's the most compelling example yet.

After having just performed an audit on the main makefile, it turns out that all targets for which it is hypothetically relevant to be passed on user-supplied LDFLAGS were already covered by the last relevant change (post #5 in this thread) with a few internal-tool exceptions which were just patched moments ago.

Caveats:

• The build process only accepts LDFLAGS and CFLAGS passed to ./configure, not to make, because (A) that's how the historical build did it and (B) that seems like a sensible policy. Without that limitation it would be easy to end up with a mix of incompatible LDFLAGS across build artifacts, e.g. libsqlite3.so and client apps which use it, leading to chaos.

• Passing custom LDFLAGS is "unsupported" and may interfere with any flags set for any specific target by the configure process. As the late Keith Medcalf was fond of saying: "if it breaks, you own both halves." (Pedantically speaking, the same applies to CFLAGS, but there are many library-level configuration flags which can only be set that way, so it's at least "somewhat supported.")