Is there no way to disable rpath?

We have long had configure script code to do that but it was commented out because it was deemed to be a "solution looking for a problem."

This checkin reactivates the --disable-rpath flag and that will part of 3.51.

Thanks for the quick reply Stephan and the commit! I’ll update my build to backport that commit into 3.50 to test the change today or in the next few days.

When I was looking into this yesterday I noticed a lot of libraries provide this --disable-rpath option so its not just SQLite specific :)

Hi, we (Fedora packaging) would also want to disable rpath for libtclsqlite3.

PoC: https://fars.ee/xc0H.patch

... also want to disable rpath for libtclsqlite3.

Can you tell us how you're building it? The extension has a couple of different approaches, one of which (the TEA-style one) is slated for removal as soon as someone (🙋) gets around to it.

In 3.54 (current trunk) --disable-rpath removes the -rpath link flag from tclsqlite3 for me and "make tclextension" does not appear to use -rpath, irrespective of that flag.

I can reproduce this with ./configure --disable-rpath && make libtcl && chrpath -l libtcl*.so on b0919c9687f01240c89171e1607816b603450e5b.

This seems to always be defined: https://sqlite.org/src/file?ci=b0919c9687f01240c89171e1607816b603450e5b&name=main.mk&ln=1652

I can reproduce this with ...

In trunk make libtcl now honors --disable-rpath. Thank you for the report!

thanks for the quick fix! we're good with not autodetecting the rpath argument style?

we're good with not autodetecting the rpath argument style?

For the main lib build detect the proper -rpath flag style using the linker. For tcl we rely on the contents of tclConfig.sh, which unfortunately formulates some of its vars as makefile var refs, but that only works when they are injected into a makefile rather than sourced via shell script, like main.mk does (noting that it is a static makefile).

We've yet to hear of any reports where that hard-coded -rpath style has failed for anyone running "make libtcl", so i'm not currently keen on adding new code to unmangle tclConfig.sh to get at the value it records when libtcl is built. If you know of such a system, though, we can do that.

I think it's possible to -include $(TCL_CONFIG_SH), does that break POSIX-make compatibility or some other rule?

I think it's possible to -include $(TCL_CONFIG_SH),

It's a shell script, not a makefile. It would almost parse as a makefile except for quotes around all values (which make would retain as part of the values):

TCL_VERSION='8.6'
...
TCL_CC_SEARCH_FLAGS='"-Wl,-rpath,${LIB_RUNTIME_DIR}"'
TCL_LD_SEARCH_FLAGS='"-Wl,-rpath,${LIB_RUNTIME_DIR}"'

Notice the single quotes around the double quotes: that's the pain point.

We can and do source that file from the make recipes which compile Tcl stuff, but at that point TCL_LD_SEARCH_FLAGS resolves to a string with another unresolved var in it, leaving us with a literal value of -Wl,-rpath,${LIB_RUNTIME_DIR}.

We could add some configure-time acrobatics to get that last bit expanded at the point where we need it, but without a broken use case the required hoop-jumping and regression risks don't seem worth it. The current approach has been in use since at least two years (when the build was last overhauled) without, to the best of my fallible recollection, a single complaint about that particular piece. If it becomes a problem, though, we know where to go looking to fix it.