Re: [fossil-users] Issue compiling with 16f1076334 and newer revisions

[Joe Prostko]

On Sun, Jul 27, 2014 at 3:22 PM, Jan Nijtmans  wrote:
> 2014-07-26 5:08 GMT+02:00 Joe Prostko :
>> Using the handy `fossil bisect`, I found that this revision is causing
>> me problems while compiling Fossil from within Haiku.
>
> Should be fixed here:
> 
>
> Thanks for the report.

Confirmed as fixed on Haiku, and compiles/works fine on this Manjaro
machine as well.  Thank you!

> The real issue was that although SQLite is supposed to be
> compiled with NDEBUG=1, this macro was defined too
> late, after the inclusion of the first . This resulted
> in the TESTONLY macro to be an empty define, but the
> assert() macro was not empty. On most platforms (e.g. linux)
> the assert() macro is re-defined every time when 
> is included again, then this problem is not noticed. However,
> it really was a problem in fossil's build system, which
> caused fossil's embedded SQLite to be compiled in
> debug mode :-( This side-effect was not intentional!

I had honed in on the problem being related to NDEBUG, but didn't get
any farther than that.  I am glad you were able to figure this out,
and that the fix helped to address a Fossil bug as well.  :)

- joe
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue compiling with 16f1076334 and newer revisions

[Jan Nijtmans]

2014-07-26 5:08 GMT+02:00 Joe Prostko :
> Using the handy `fossil bisect`, I found that this revision is causing
> me problems while compiling Fossil from within Haiku.

Should be fixed here:


Thanks for the report.

The real issue was that although SQLite is supposed to be
compiled with NDEBUG=1, this macro was defined too
late, after the inclusion of the first . This resulted
in the TESTONLY macro to be an empty define, but the
assert() macro was not empty. On most platforms (e.g. linux)
the assert() macro is re-defined every time when 
is included again, then this problem is not noticed. However,
it really was a problem in fossil's build system, which
caused fossil's embedded SQLite to be compiled in
debug mode :-( This side-effect was not intentional!

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue compiling with 16f1076334 and newer revisions

[Joe Prostko]

On Fri, Jul 25, 2014 at 11:08 PM, Joe Prostko  wrote:
> Using the handy `fossil bisect`, I found that this revision is causing
> me problems while compiling Fossil from within Haiku.

I did some more digging, and the problem seems to be that the assert.h
included from within config.h is causing problems when sqlite3.c
includes config.h due to _HAVE_SQLITE_CONFIG_H being defined.

I did a dirty workaround of copying config.h to jpconfig.h, and then
commenting out the include line for assert.h on line 55 of jpconfig.h.
I then edited sqlite3.c to include jpconfig.h instead of config.h on
line 7635.  All other files that include config.h build just fine, as
the only file that has problems with config.h in its original form is
sqlite3.c.  Things compile and run just fine when jpconfig.h is
included by sqlite3.c instead of config.h.

I played around a bit to try to get some sort of clever header guard
in place, but ultimately it didn't work...or wasn't clever enough.  ;)

If somebody more familiar with all of the code has any ideas, that
would be appreciated.  I'm sure I'm overlooking something obvious to
fix this, all without negatively affecting other platforms.  I thought
I could find the answer by looking at the SQLite codebase, but well,
it generates its config.h during configure, and it looks nothing like
the config.h included with Fossil, that's for sure.

Also, in case it's useful, here's the assert.h that is used by Haiku.

http://cgit.haiku-os.org/haiku/tree/headers/posix/assert.h

I'll probably look at this all again tomorrow if nobody has any ideas,
but wanted to share my latest findings.

- joe
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Issue compiling with 16f1076334 and newer revisions

[Joe Prostko]

Using the handy `fossil bisect`, I found that this revision is causing
me problems while compiling Fossil from within Haiku.

This revision brought in -D_HAVE_SQLITE_CONFIG_H and in theory should
work on platforms that support utime() and usleep().  In any case, I
have found that for Haiku anyway, the build fails with this revision
or better, unless I get rid of -D_HAVE_SQLITE_CONFIG_H in Makefile.in.

I admit I didn't really dig into this at all yet, but in any case, the
build fails with both GCC 2.95.3 and GCC 4.8.3 on Haiku.  I'm not sure
why it is happening as of yet.  I suspect it will come down to the
compiler not liking something with respect to typedef'ing structs
though, as I admit this failure seems familiar to me.

Below is the output from revision ffef4edceb with GCC 4.8.3 (since it
is more verbose) in case Jan or anyone else can make sense of it
before I get a chance to try to dig deeper into the situation.


cc -I/packages/openssl-1.0.0m-2/.self/develop/headers-g -O2
-DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H  -I. -I./src -Ibld
-DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_ENABLE_LOCKING_STYLE=0
-DSQLITE_THREADSAFE=0 -DSQLITE_DEFAULT_FILE_FORMAT=4
-DSQLITE_OMIT_DEPRECATED -DSQLITE_ENABLE_EXPLAIN_COMMENTS  -c
./src/sqlite3.c -o bld/sqlite3.o
In file included from ./src/config.h:55:0,
 from ./src/sqlite3.c:7635:
./src/sqlite3.c: In function 'pcache1TruncateUnsafe':
./src/sqlite3.c:38822:26: error: 'nPage' undeclared (first use in this function)
   assert( pCache->nPage==nPage );
  ^
./src/sqlite3.c:38822:26: note: each undeclared identifier is reported
only once for each function it appears in
./src/sqlite3.c: In function 'sqlite3WalFindFrame':
./src/sqlite3.c:49527:36: error: 'Wal' has no member named 'lockError'
   assert( pWal->readLock>=0 || pWal->lockError );
^
./src/sqlite3.c: In function 'sqlite3WalExclusiveMode':
./src/sqlite3.c:50265:36: error: 'Wal' has no member named 'lockError'
   assert( pWal->readLock>=0 || pWal->lockError );
^
./src/sqlite3.c: In function 'cellSizePtr':
./src/sqlite3.c:52346:18: error: 'debuginfo' undeclared (first use in
this function)
   assert( nSize==debuginfo.nSize );
  ^
./src/sqlite3.c: In function 'autoVacuumCommit':
./src/sqlite3.c:54514:11: error: 'nRef' undeclared (first use in this function)
   assert( nRef>=sqlite3PagerRefcount(pPager) );
   ^
./src/sqlite3.c: In function 'balance':
./src/sqlite3.c:58117:18: error: 'balance_deeper_called' undeclared
(first use in this function)
 assert( (balance_deeper_called++)==0 );
  ^
./src/sqlite3.c:58156:20: error: 'balance_quick_called' undeclared
(first use in this function)
   assert( (balance_quick_called++)==0 );
^
./src/sqlite3.c: In function 'sqlite3_backup_step':
./src/sqlite3.c:60361:15: error: 'rc2' undeclared (first use in this function)
   assert( rc2==SQLITE_OK );
   ^
./src/sqlite3.c: In function 'sqlite3VdbeSorterWrite':
./src/sqlite3.c:75447:31: error: 'nExpect' undeclared (first use in
this function)
 assert( rc!=SQLITE_OK || (nExpect==pSorter->iWriteOff) );
   ^
./src/sqlite3.c: In function 'sqlite3ExprCodeTarget':
./src/sqlite3.c:80833:36: error: 'iCacheLevel' undeclared (first use
in this function)
|| pParse->iCacheLevel==iCacheLevel );
^
./src/sqlite3.c: In function 'sqlite3DeleteTable':
./src/sqlite3.c:86185:15: error: 'pOld' undeclared (first use in this function)
   assert( pOld==pIndex || pOld==0 );
   ^
./src/sqlite3.c:86208:11: error: 'nLookaside' undeclared (first use in
this function)
   assert( nLookaside==0 || nLookaside==db->lookaside.nOut );
   ^
./src/sqlite3.c: In function 'sqlite3InitCallback':
./src/sqlite3.c:100108:25: error: 'rcp' undeclared (first use in this function)
 assert( (rc&0xFF)==(rcp&0xFF) );
 ^
./src/sqlite3.c: In function 'execSql':
./src/sqlite3.c:108467:11: error: 'rc' undeclared (first use in this function)
   assert( rc!=SQLITE_ROW || (db->flags&SQLITE_CountRows) );
   ^
make: *** [bld/sqlite3.o] Error 1
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users