Opened 13 months ago

Last modified 13 months ago

#72798 new defect

base does not work if built with ppc64 slice: sqlite error: string or blob too big (18) while executing query

Reported by: barracuda156 Owned by:
Priority: Normal Milestone:
Component: base Version: 2.11.4
Keywords: ppc64, leopard Cc:
Port:

Description

For some reason if I build the base for ppc+ppc64, it does not work correctly, giving this on any call to install/activate:

sqlite error: string or blob too big (18) while executing query: SELECT id FROM registry.ports INDEXED BY port_name WHERE name=? AND version=? AND revision=? AND variants=? AND epoch!=?

ppc-only version works normally.

Any idea why this may be the case?

Change History (3)

comment:1 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)

Sounds like a bug in sqlite3, at least the version of sqlite3 bundled with the version of tcl we're using.

comment:2 in reply to:  1 Changed 13 months ago by barracuda156

Replying to ryandesign:

Sounds like a bug in sqlite3, at least the version of sqlite3 bundled with the version of tcl we're using.

One likely issue is that tclsqlite3 sets pointer size to 4 bytes on ppc64 (while in sqlite3 itself that was fixed, and pointer is set to 8 bytes, as for other 64-bit archs), however patching that did not fix the issue for me.

Just for the reference, what I tried (but no change to the perceived outcome):

--- a/vendor/tcl8.6.16/pkgs/sqlite3.47.2/generic/tclsqlite3.c	2025-08-01 07:15:34.000000000 +0800
+++ b/vendor/tcl8.6.16/pkgs/sqlite3.47.2/generic/tclsqlite3.c	2025-08-08 06:32:43.000000000 +0800
@@ -75,7 +75,7 @@
 #     define SQLITE_PTRSIZE __SIZEOF_POINTER__
 #   elif defined(i386)     || defined(__i386__)   || defined(_M_IX86) ||    \
          defined(_M_ARM)   || defined(__arm__)    || defined(__x86)   ||    \
-        (defined(__APPLE__) && defined(__POWERPC__)) ||                     \
+        (defined(__APPLE__) && defined(__ppc__)) ||                     \
         (defined(__TOS_AIX__) && !defined(__64BIT__))
 #     define SQLITE_PTRSIZE 4
 #   else

--- a/vendor/tcl8.6.16/pkgs/sqlite3.47.2/compat/sqlite3/shell.c	2025-08-01 07:15:34.000000000 +0800
+++ b/vendor/tcl8.6.16/pkgs/sqlite3.47.2/compat/sqlite3/shell.c	2025-08-08 06:31:37.000000000 +0800
@@ -2431,7 +2431,7 @@
      defined(_M_AMD64) || defined(_M_ARM)     || defined(__x86)   ||    \
      defined(__arm__)
 #   define SHA3_BYTEORDER    1234
-# elif defined(sparc)    || defined(__ppc__)
+# elif defined(sparc)    || defined(__POWERPC__)
 #   define SHA3_BYTEORDER    4321
 # else
 #   define SHA3_BYTEORDER 0
  1. S. We can survive with 32-bit MacPorts on ppc64, of course, since it still can build ppc64 ports, but it would be nice to track down the bug, especially if it is in sqlite3 rather that MacPorts-specific code.

comment:3 in reply to:  1 Changed 13 months ago by barracuda156

Replying to ryandesign:

Sounds like a bug in sqlite3, at least the version of sqlite3 bundled with the version of tcl we're using.

I just thought, how is it gonna work with a universal build when arch flags are passed at once? It seems that __ppc__ will be defined, and SQLITE_PTRSIZE will be set to 4, for both archs. Am I right?

Note: See TracTickets for help on using tickets.