Re: [sqlite] Compiling Problem With SQLite 3.5.4
Zbigniew Baniewski wrote: On Sat, Dec 15, 2007 at 12:48:44PM -0500, Robert L Cochran wrote: I did a poor job of explaining this issue. GCC builds of 3.5.4 seem to fail. I've sent Richard a bunch of log files comparing source code builds of versions 3.5.3 and 3.5.4 showing what I believe are symptoms of the alleged failure. If anyone wants copies of the same set of files, feel free to contact me. Just out of curiosity made a compilation of 3.5.4: apart of some warnings (below) no errors at all. cp: uwaga: plik źródłowy `./src/btree.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./src/hash.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./src/sqliteInt.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./src/vdbe.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./ext/fts1/fts1.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./ext/fts1/fts1_hash.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./ext/fts1/fts1_tokenizer.h' pojawił się więcej niż raz (it means: "cp: warning: source file `..' appears more than once") Compiled on: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Linux with kernel 2.6.22 Pentium II One additional comment: Tcl's 8.5 "package require" isn't as tollerant about version marks, as in 8.4.x line it used to. So, the proper pgIndex.tcl contents should contain the subversion digit as well, instead of just "3.5" - I mean: package ifneeded sqlite3 3.5.4 [list load /usr/local/lib/tcl8.5/sqlite3/libtclsqlite3.so sqlite3] Yes, I agree completely. 'make' wasn't issuing the 'creating sqlite3' message I've been so accustomed to, and the cp messages about duplicates concerned me. Christian supplied me some patches to get rid of the size messages and Richard told me they got rid of the creating message, 'make install' worked fine, and I have version 3.5.4 (with Christian's patches) running. Bob - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
On Sat, Dec 15, 2007 at 12:48:44PM -0500, Robert L Cochran wrote: > I did a poor job of explaining this issue. GCC builds of 3.5.4 seem to > fail. I've sent Richard a bunch of log files comparing source code > builds of versions 3.5.3 and 3.5.4 showing what I believe are symptoms > of the alleged failure. If anyone wants copies of the same set of files, > feel free to contact me. Just out of curiosity made a compilation of 3.5.4: apart of some warnings (below) no errors at all. cp: uwaga: plik źródłowy `./src/btree.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./src/hash.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./src/sqliteInt.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./src/vdbe.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./ext/fts1/fts1.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./ext/fts1/fts1_hash.h' pojawił się więcej niż raz cp: uwaga: plik źródłowy `./ext/fts1/fts1_tokenizer.h' pojawił się więcej niż raz (it means: "cp: warning: source file `..' appears more than once") Compiled on: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Linux with kernel 2.6.22 Pentium II One additional comment: Tcl's 8.5 "package require" isn't as tollerant about version marks, as in 8.4.x line it used to. So, the proper pgIndex.tcl contents should contain the subversion digit as well, instead of just "3.5" - I mean: package ifneeded sqlite3 3.5.4 [list load /usr/local/lib/tcl8.5/sqlite3/libtclsqlite3.so sqlite3] -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
Following patch applied to the CVS version compiled
w/o warnings on a CentOS 5 x86_64 box. But I didn't
run the test yet ... and autoconf logic regarding
availability of ptrdiff_t is missing, too.
Index: src/func.c
===
RCS file: /sqlite/sqlite/src/func.c,v
retrieving revision 1.181
diff -r1.181 func.c
878c878
< int flags;/* 1: trimleft 2: trimright 3: trim */
---
> ptrdiff_t flags; /* 1: trimleft 2: trimright 3: trim */
919c919
< flags = (int)sqlite3_user_data(context);
---
> flags = (ptrdiff_t)sqlite3_user_data(context);
1464c1464
< pArg = (void*)(int)argType;
---
> pArg = (void*)(ptrdiff_t)argType;
1483c1483
< void *pArg = (void*)(int)aAggs[i].argType;
---
> void *pArg = (void*)(ptrdiff_t)aAggs[i].argType;
Index: src/table.c
===
RCS file: /sqlite/sqlite/src/table.c,v
retrieving revision 1.29
diff -r1.29 table.c
36c36
< int nData;
---
> ptrdiff_t nData;
197c197,198
< int i, n;
---
> int i;
> ptrdiff_t n;
200c201
< n = (int)azResult[0];
---
> n = (ptrdiff_t)azResult[0];
Index: src/vdbemem.c
===
RCS file: /sqlite/sqlite/src/vdbemem.c,v
retrieving revision 1.84
diff -r1.84 vdbemem.c
878c878
< if( (enc & SQLITE_UTF16_ALIGNED)!=0 && 1==(1&(int)pVal->z) ){
---
> if( (enc & SQLITE_UTF16_ALIGNED)!=0 && 1==(1&(ptrdiff_t)pVal->z) ){
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Compiling Problem With SQLite 3.5.4
[EMAIL PROTECTED] wrote: Robert L Cochran <[EMAIL PROTECTED]> wrote: While compiling version 3.5.4 using gcc, I got these messages from 'make' on my CentOS 5 host. It looks to me like the 'make' step failed. I can post the config.log if that would help. How can I fix this to get a successful compile? I don't see any errors in your make output, only warnings. Did I overlook something, or are you concerned about the warnings. The warnings all have to do with the fact that you are compiling on a machine with 64-bit pointers and 32-bit integers. The warnings are all harmless and the code works as intended as long as sizeof(int) <= sizeof(void*) Perhaps a reader can suggest ways of eliminating these warnings. -- D. Richard Hipp <[EMAIL PROTECTED]> I did a poor job of explaining this issue. GCC builds of 3.5.4 seem to fail. I've sent Richard a bunch of log files comparing source code builds of versions 3.5.3 and 3.5.4 showing what I believe are symptoms of the alleged failure. If anyone wants copies of the same set of files, feel free to contact me. Bob - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
[EMAIL PROTECTED] wrote: > > Christian Werner <[EMAIL PROTECTED]> wrote: > > > > What about using the ptrdiff_t type in those places instead. > > > > Is ptrdiff_t implemented on all C compiler environments that > SQLite builds on? I'm afraid not, thus some autoconf logic might be required to detect its availability. > Also, will it really eliminate the warnings. In several places > we are storing a (32-bit) integer in a pointer. > > p = (char*)i; > > And then later we get the integer back out: > > i = (int)p; When the context allows to change i's type to ptrdiff_t then you get i = (ptrdift_t)p; which eliminates the warning. > If we change to ptrdiff_t, then we have: > > p = (char*)(ptrdiff_t)i; /* Convoluted, but works */ > i = (int)(ptrdiff_t)p;/* Still get a warning? */ > > In the conversion from pointer back to integer, don't we still > get a warning about casting a 64-bit integer into a 32-bit > integer? (I don't know because I do not have a 64-bit machine > easily at hand to test it on.) See above, when it's irrelevant if i is a 32 or 64 bit data type, the 32 vs. 64 bit warning blues is gone. Regards, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
Christian Werner <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > ... > > The warnings all have to do with the fact that you are > > compiling on a machine with 64-bit pointers and 32-bit > > integers. The warnings are all harmless and the code > > works as intended as long as > > > > sizeof(int) <= sizeof(void*) > > > > Perhaps a reader can suggest ways of eliminating these > > warnings. > > What about using the ptrdiff_t type in those places instead. > Is ptrdiff_t implemented on all C compiler environments that SQLite builds on? Also, will it really eliminate the warnings. In several places we are storing a (32-bit) integer in a pointer. p = (char*)i; And then later we get the integer back out: i = (int)p; If we change to ptrdiff_t, then we have: p = (char*)(ptrdiff_t)i; /* Convoluted, but works */ i = (int)(ptrdiff_t)p;/* Still get a warning? */ In the conversion from pointer back to integer, don't we still get a warning about casting a 64-bit integer into a 32-bit integer? (I don't know because I do not have a 64-bit machine easily at hand to test it on.) -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
[EMAIL PROTECTED] wrote: > ... > The warnings all have to do with the fact that you are > compiling on a machine with 64-bit pointers and 32-bit > integers. The warnings are all harmless and the code > works as intended as long as > > sizeof(int) <= sizeof(void*) > > Perhaps a reader can suggest ways of eliminating these > warnings. What about using the ptrdiff_t type in those places instead. Cheers, Christian - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Compiling Problem With SQLite 3.5.4
Robert L Cochran <[EMAIL PROTECTED]> wrote: > While compiling version 3.5.4 using gcc, I got these messages from > 'make' on my CentOS 5 host. It looks to me like the 'make' step failed. > I can post the config.log if that would help. > > How can I fix this to get a successful compile? > I don't see any errors in your make output, only warnings. Did I overlook something, or are you concerned about the warnings. The warnings all have to do with the fact that you are compiling on a machine with 64-bit pointers and 32-bit integers. The warnings are all harmless and the code works as intended as long as sizeof(int) <= sizeof(void*) Perhaps a reader can suggest ways of eliminating these warnings. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
