To develop another project under Solaris 9 (sparc), I decided first to build Fossil to use it as VCS for my project. Unfortunately it was not possible to build it streight ahead. Following was necessary:

  1  <samp>sha1.c</samp> ought to be patched via <verbatim>--- src/sha1.c  Thu May 28 02:44:38 2009
+++ Sat Jun  6 18:07:39 2009
@@ -2,7 +2,12 @@
 ** This implementation of SHA1 is adapted from the example implementation
 ** contained in RFC-3174.
 */
-#include <stdint.h>
+#ifdef __sparc__
+  typedef unsigned int uint32_t;
+  typedef unsigned char uint8_t;
+#else
+# include <stdint.h>
+#endif
 #include <sys/types.h>
 #include "config.h"
 #include "sha1.h"</verbatim>

  2  The binary <samp>fossil</samp> has to be linked with <samp>-lsocket -lnsl</samp>

After these, the binary could be built. But using it to e.g. clone or rebuild an existing repository, will result in a bus error with core dump. A debugger excerpt shows:<verbatim>bash-2.05$ ./fossil clone t3x.fsl
 Repository cloned into t3x.fsl
 Rebuilding repository meta-data...
Bus Error (core dumped)
bash-2.05$ gdb fossil core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.9"...
Core was generated by `./fossil clone t3x.fsl'.
Program terminated with signal 10, Bus Error.
Reading symbols from
Loaded symbols for
Reading symbols from
Loaded symbols for
Reading symbols from
Loaded symbols for
Reading symbols from
Loaded symbols for
Reading symbols from
Loaded symbols for
Reading symbols from
Loaded symbols for
Reading symbols from
Loaded symbols for
#0  sqlite3RowSetInsert (p=0x10e7a0, rowid=16) at src/sqlite3.c:30020
30020     pEntry->v = rowid;
(gdb) bt
#0  sqlite3RowSetInsert (p=0x10e7a0, rowid=16) at src/sqlite3.c:30020
#1  0x71410 in sqlite3VdbeExec (p=0xff568) at src/sqlite3.c:54628
#2  0x6c4dc in sqlite3Step (p=0xff568) at src/sqlite3.c:49092
#3  0x6c624 in sqlite3_step (pStmt=0xff568) at src/sqlite3.c:49168
#4  0x85f5c in sqlite3_exec (db=0xf54f8, zSql=0xff668 "DROP TABLE 'filename'",
    xCallback=0, pArg=0x0, pzErrMsg=0xffbffa3c) at src/sqlite3.c:5421
#5  0x29af4 in db_multi_exec (zSql=0xc2ae0 "DROP TABLE %Q") at db_.c:390
#6  0x3cdc4 in rebuild_db (randomize=0, doOut=1039808) at rebuild_.c:221
#7  0x27288 in clone_cmd () at clone_.c:94
#8  0x3579c in main (argc=0, argv=0xffbffc5c) at main_.c:248
(gdb) p pEntry
No symbol "pEntry" in current context.
(gdb) list
30015       p->pFresh = pNew->aEntry;
30016       p->nFresh = ROWSET_ENTRY_PER_CHUNK;
30017     }
30018     pEntry = p->pFresh++;
30019     p->nFresh--;
30020     pEntry->v = rowid;
30021     pEntry->pRight = 0;
30022     pLast = p->pLast;
30023     if( pLast ){
30024       if( p->isSorted && rowid<=pLast->v ){
(gdb) info loc
pLast = (struct RowSetEntry *) 0x0
(gdb) quit</verbatim>

However, if I took the file <samp>sqlite3.c</samp> of revision [767ae79c3d] replacing the actual file of revision [915bfd99fe], then all will run correctly without any fault!

So I assume, the error was introduced in revision [3b76c0474e] (SQLite as replacing the faulty file with that revision's one, also caused a bus error.

If further information is necessary, please let me know ...

Ciao,
:-)