Description

robertkirkman

opened on Aug 17, 2026

Issue body actions

Hello, there are many references to "sqlite" in the software,

sqlcipher/sqlite.pc.in

Line 11 in 810db22

Libs: -L${libdir} -lsqlite

I understand that sqlcipher is a near-ABI-compatible soft fork of sqlite, leading to many internal instances of sqlite that might be difficult for you to automatically rename, but unfortunately, the instances of sqlite are polluting outwards into distributions of the software and conflicting with the file names of the upstream files in the sqlite packages in the same distributions.

This has led to the need for many distributions to modify the files of the sqlcipher software post-installation in a convoluted way, including but not limited to:

• Debian
• Arch Linux
• OpenSUSE
• LigurOS
• Termux
• OpenMamba
• OpenBSD
• FreeBSD

and unfortunately, I am struggling with this problem and the need to manually script renaming the files to avoid conflicts is frustrating to handle in my distribution's build framework.

There is an option libsqlite3.DLL.basename that can be set to sqlcipher, to rename some of the files successfully,

sqlcipher/main.mk

Line 1114 in 810db22

libsqlite3.DLL.basename ?= libsqlite3

However, it only renames these specific files:

What libsqlite3.DLL.basename=libsqlcipher does

before	after
libsqlite3.so.3.53.3	libsqlcipher.so.3.53.3
libsqlite3.so.0	libsqlcipher.so.0
libsqlite3.so	libsqlcipher.so

it does not rename these specific other files that are also installed alongside libsqlcipher.so into the distributed package:

• sqlite3
• sqlite3.h
• sqlite3ext.h
• sqlite3.pc
• sqlite3.1.gz

I believe that providing one or more additional options alongside libsqlite3.DLL.basename that could be used to preemptively rename the rest of the conflicting files to sqlcipher* instead of sqlite3* would be very helpful for all future distributions of sqlcipher and also for future updates to all of the above preexisting distributions, to adopt the new variables and dramatically simplify their build scripts.

Activity

1. sjlombardo commented on Aug 17, 2026

   

   sjlombardo

   on Aug 17, 2026

   Member

   More actions

   Hello @robertkirkman - Thanks for getting in touch about this. The list of distributions is helpful for context.

   One of the major concerns here is that we try hard not to stray too far from the upstream SQLite build system. We made the mistake once before of patching the build system, renaming resources, etc, and it caused no end of trouble. We were only able to step back from that undesirable state in 4.7.0. One of our major goals, including with the upcoming SQLCipher 5 release, is to significantly reduce upstream differences, not add more.

   I would also like to reference an in-depth discussion that took place in ticket #488. Despite the fact that the title is related to SONAME, some of the later discussion there specifically deals with renaming, OS packages, etc, and is very relevant to this topic. Specifically, the comment I added on 2025-03-26 includes almost all of the background history for this project, as well as the details of the upstream realignment I mentioned earlier.

   Additionally, Debian's approach of relocating headers under a separate directory (placing them in /usr/include/sqlcipher to avoid collisions without renaming any files) might be helpful in your case as well.

   Once things free up a bit more we may consider potential build options further.

   Reacted by Robert Kirkman and Niraj Giri
2. robertkirkman commented on Aug 22, 2026

   

   robertkirkman

   on Aug 22, 2026

   Author

   More actions

   I have created this in order to work around my problem,

   --- a/autosetup/sqlite-config.tcl
   +++ b/autosetup/sqlite-config.tcl
   @@ -1619,7 +1619,7 @@ proc sqlite-handle-dll-basename {} {
        set dn [join [opt-val dll-basename] ""]
        if {$dn in {none default}} { set dn libsqlite3 }
      } else {
   -    set dn libsqlite3
   +    set dn libsqlcipher
      }
      if {$dn in {auto ""}} {
        switch -glob -- [get-define host] {
   --- a/main.mk
   +++ b/main.mk
   @@ -1636,7 +1636,8 @@ install: install-lib
    # Install C header files
    #
    install-headers: sqlite3.h $(install-dir.include)
   -	$(INSTALL.noexec) sqlite3.h "$(TOP)/src/sqlite3ext.h" "$(install-dir.include)"
   +	$(INSTALL.noexec) sqlite3.h                 "$(install-dir.include)/sqlcipher.h"
   +	$(INSTALL.noexec) "$(TOP)/src/sqlite3ext.h" "$(install-dir.include)/sqlcipherext.h"
    install: install-headers
    
    #
   @@ -2210,7 +2211,7 @@ sqlite3d$(T.exe):	shell.c $(LIBOBJS0)
    		$(LDFLAGS.libsqlite3) $(LDFLAGS.readline)
    
    install-shell-0: sqlite3$(T.exe) $(install-dir.bin)
   -	$(INSTALL) sqlite3$(T.exe) "$(install-dir.bin)"
   +	$(INSTALL) sqlite3$(T.exe) "$(install-dir.bin)/sqlcipher"
    install-shell-1:
    install: install-shell-$(HAVE_WASI_SDK)
    
   @@ -2251,14 +2252,15 @@ install-rsync: sqlite3_rsync$(T.exe) $(install-dir.bin)
    #install: install-rsync
    
    install-man1: $(install-dir.man1)
   -	$(INSTALL.noexec) "$(TOP)/sqlite3.1" "$(install-dir.man1)"
   +	$(INSTALL.noexec) "$(TOP)/sqlite3.1" "$(install-dir.man1)/sqlcipher.1"
    install: install-man1
    
    #
    # sqlite3.pc is typically generated by the configure script but could
    # conceivably be generated by hand.
    install-pc: sqlite3.pc $(install-dir.pkgconfig)
   -	$(INSTALL.noexec) sqlite3.pc "$(install-dir.pkgconfig)"
   +	sed -i 's/sqlite3/sqlcipher/g' sqlite3.pc
   +	$(INSTALL.noexec) sqlite3.pc "$(install-dir.pkgconfig)/sqlcipher.pc"
    
    srcck1$(B.exe):	$(TOP)/tool/srcck1.c
    	$(B.cc) -o srcck1$(B.exe) $(TOP)/tool/srcck1.c

   if this is the type of change that another distributor would like to use, then maybe it could be revised to only activate when a build flag is passed and not modify the default behavior, then submitted as a PR either to sqlcipher, or to sqlite to then be inherited by sqlcipher.

Issue actions