Re: [sqlite] SQLite on Motorola Power PC
On Wed, 20 Apr 2005, Ted Unangst wrote:
>Christian Smith wrote:
>> On Mon, 18 Apr 2005, Cem Vedat ISIK wrote:
>>
>>
>>>Having a lot of cross compiling trials and errors, I have decided not to
>>>cross compile, but to compile the SQLite on Motorola PowerPC itself.
>>
>>
>>
>> If this is still the config.h issue, I have made some changes to allow
>> compiling without config.h being generated. It's only used for dodgy
>> pointer arithmatic in a couple of places, and can be done more portably
>> without converting pointers to integers.
>>
>> Try the attached patch, against the latest CVS source, which removes the
>> need for config.h, hence removing the need to generate config.h. I've not
>> removed config.h from Makefile.in or Makefile.linux-gcc. All tests on
>> Linux x86 with gcc 3.3.3 pass OK with this code. Not tested on other
>> platforms or cross-compile. Apply patch (in sqlite directory) with:
>
>Looks like it will deref 0 to get Timeout in some cases.
>
No, it's worse than that. sqliteDefaultBusyCallback() will always get a
pointer, but it will get a pointer to an int that no longer exists
(sqliteDefaultBusyCallback() is called when the database is busy, not when
sqlite3_busy_timeout() is called, and so will point to garbage.
In this case, the timeout for sqlite3_busy_timeout() should be converted
to a pointer and passed as before. However, as sizeof(int)<=sizeof(void*)
on all platforms I know of, there should be no problems simply casting the
int to a void* and then casting back in sqliteDefaultBusyCallback().
Updated patch against CVS head attached.
Christian
--
/"\
\ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \Index: src/btree.c
===
RCS file: /sqlite/sqlite/src/btree.c,v
retrieving revision 1.256
diff -u -r1.256 btree.c
--- src/btree.c 29 Mar 2005 13:17:46 - 1.256
+++ src/btree.c 21 Apr 2005 09:50:01 -
@@ -1216,8 +1216,10 @@
assert( sizeof(u32)==4 );
assert( sizeof(u16)==2 );
assert( sizeof(Pgno)==4 );
+#if 0
assert( sizeof(ptr)==sizeof(char*) );
assert( sizeof(uptr)==sizeof(ptr) );
+#endif
pBt = sqliteMalloc( sizeof(*pBt) );
if( pBt==0 ){
Index: src/build.c
===
RCS file: /sqlite/sqlite/src/build.c,v
retrieving revision 1.318
diff -u -r1.318 build.c
--- src/build.c 29 Mar 2005 03:10:59 - 1.318
+++ src/build.c 21 Apr 2005 09:50:01 -
@@ -1510,7 +1510,7 @@
if( pSelect ){
zStmt = createTableStmt(p);
}else{
- n = Addr(pEnd->z) - Addr(pParse->sNameToken.z) + 1;
+ n = pEnd->z - pParse->sNameToken.z + 1;
zStmt = sqlite3MPrintf("CREATE %s %.*s", zType2, n,
pParse->sNameToken.z);
}
@@ -2463,7 +2463,7 @@
/* A named index with an explicit CREATE INDEX statement */
zStmt = sqlite3MPrintf("CREATE%s INDEX %.*s",
onError==OE_None ? "" : " UNIQUE",
-Addr(pEnd->z) - Addr(pName->z) + 1,
+pEnd->z - pName->z + 1,
pName->z);
}else{
/* An automatic index created by a PRIMARY KEY or UNIQUE constraint */
Index: src/expr.c
===
RCS file: /sqlite/sqlite/src/expr.c,v
retrieving revision 1.197
diff -u -r1.197 expr.c
--- src/expr.c 21 Mar 2005 03:53:38 - 1.197
+++ src/expr.c 21 Apr 2005 09:50:01 -
@@ -265,7 +265,7 @@
assert( pLeft->dyn==0 || pLeft->z[pLeft->n]==0 );
if( pLeft->dyn==0 && pRight->dyn==0 ){
pExpr->span.z = pLeft->z;
- pExpr->span.n = pRight->n + Addr(pRight->z) - Addr(pLeft->z);
+ pExpr->span.n = pRight->n + (pRight->z - pLeft->z);
}else{
pExpr->span.z = 0;
}
Index: src/main.c
===
RCS file: /sqlite/sqlite/src/main.c,v
retrieving revision 1.285
diff -u -r1.285 main.c
--- src/main.c 29 Mar 2005 23:34:58 - 1.285
+++ src/main.c 21 Apr 2005 09:50:01 -
@@ -623,8 +623,8 @@
static const short int totals[] =
{ 0, 1, 3, 8, 18, 33, 53, 78, 103, 128, 178, 228, 287};
# define NDELAY (sizeof(delays)/sizeof(delays[0]))
- ptr timeout = (ptr)Timeout;
- ptr delay, prior;
+ int timeout = (int)Timeout;
+ int delay, prior;
if( count <= NDELAY ){
delay = delays[count-1];
@@ -699,7 +699,7 @@
*/
int sqlite3_busy_timeout(sqlite3 *db, int ms){
if( ms>0 ){
-sqlite3_busy_handler(db, sqliteDefaultBusyCallback, (void*)(ptr)ms);
+sqlite3_busy_handler(db, sqliteDefaultBusyCallback, (void*)ms);
}else{
sqlite3_busy_handler(db, 0, 0);
}
Index: src/sqliteInt.h
===
RCS file: /sqlite/sqlite/src/sqliteInt.h,v
retrieving revision 1.375
diff -u -r1.375 sqliteInt.h
--- src/sqliteInt.h 29 Mar 2005 03:10:59 - 1.375
+++ src/sqliteInt.h 21 Apr 2005 09:50:01 -
@@ -39,7 +39,9
Re: [sqlite] SQLite on Motorola Power PC
Christian Smith wrote: On Mon, 18 Apr 2005, Cem Vedat ISIK wrote: Having a lot of cross compiling trials and errors, I have decided not to cross compile, but to compile the SQLite on Motorola PowerPC itself. If this is still the config.h issue, I have made some changes to allow compiling without config.h being generated. It's only used for dodgy pointer arithmatic in a couple of places, and can be done more portably without converting pointers to integers. Try the attached patch, against the latest CVS source, which removes the need for config.h, hence removing the need to generate config.h. I've not removed config.h from Makefile.in or Makefile.linux-gcc. All tests on Linux x86 with gcc 3.3.3 pass OK with this code. Not tested on other platforms or cross-compile. Apply patch (in sqlite directory) with: Looks like it will deref 0 to get Timeout in some cases. -- Ted Unangst www.coverity.com Coverity, Inc.
Re: [sqlite] SQLite on Motorola Power PC
On Mon, 18 Apr 2005, Cem Vedat ISIK wrote:
>Having a lot of cross compiling trials and errors, I have decided not to
>cross compile, but to compile the SQLite on Motorola PowerPC itself.
If this is still the config.h issue, I have made some changes to allow
compiling without config.h being generated. It's only used for dodgy
pointer arithmatic in a couple of places, and can be done more portably
without converting pointers to integers.
Try the attached patch, against the latest CVS source, which removes the
need for config.h, hence removing the need to generate config.h. I've not
removed config.h from Makefile.in or Makefile.linux-gcc. All tests on
Linux x86 with gcc 3.3.3 pass OK with this code. Not tested on other
platforms or cross-compile. Apply patch (in sqlite directory) with:
$ patch -p0 < patch
>I have the gcc version 2.95.4. When I run "make" after some time, I see
>
>gcc: Internal compiler error: program cc1 got fatal signal 9
>make: *** [sqlite3] Error 1
>
>I think that I'm having this problem because of the RAM size oy my Power
>PC System. It has 16 MB installed RAM and have tried the same compiling
>scenario with 32 MB RAM installed. That time the same error message
>appeared a little later which means it could manage to compile some more
>stuff and then killed by signal 9... By the way I've observed that the
>kill signal is generated by kernel when a process uses a lot of RAM.
>
>Is there any information about How mant bytes of RAM does SQLite need
>to be compiled/built?
>According to that information I'll try to modify my system RAM or do
>something else to get SQLite run on Power PC.
>Any ideas/suggestions or comments will be appreciated.
>
>
--
/"\
\ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \Index: src/btree.c
===
RCS file: /sqlite/sqlite/src/btree.c,v
retrieving revision 1.256
diff -u -r1.256 btree.c
--- src/btree.c 29 Mar 2005 13:17:46 - 1.256
+++ src/btree.c 20 Apr 2005 16:46:24 -
@@ -1216,8 +1216,10 @@
assert( sizeof(u32)==4 );
assert( sizeof(u16)==2 );
assert( sizeof(Pgno)==4 );
+#if 0
assert( sizeof(ptr)==sizeof(char*) );
assert( sizeof(uptr)==sizeof(ptr) );
+#endif
pBt = sqliteMalloc( sizeof(*pBt) );
if( pBt==0 ){
Index: src/build.c
===
RCS file: /sqlite/sqlite/src/build.c,v
retrieving revision 1.318
diff -u -r1.318 build.c
--- src/build.c 29 Mar 2005 03:10:59 - 1.318
+++ src/build.c 20 Apr 2005 16:46:25 -
@@ -1510,7 +1510,7 @@
if( pSelect ){
zStmt = createTableStmt(p);
}else{
- n = Addr(pEnd->z) - Addr(pParse->sNameToken.z) + 1;
+ n = pEnd->z - pParse->sNameToken.z + 1;
zStmt = sqlite3MPrintf("CREATE %s %.*s", zType2, n,
pParse->sNameToken.z);
}
@@ -2463,7 +2463,7 @@
/* A named index with an explicit CREATE INDEX statement */
zStmt = sqlite3MPrintf("CREATE%s INDEX %.*s",
onError==OE_None ? "" : " UNIQUE",
-Addr(pEnd->z) - Addr(pName->z) + 1,
+pEnd->z - pName->z + 1,
pName->z);
}else{
/* An automatic index created by a PRIMARY KEY or UNIQUE constraint */
Index: src/expr.c
===
RCS file: /sqlite/sqlite/src/expr.c,v
retrieving revision 1.197
diff -u -r1.197 expr.c
--- src/expr.c 21 Mar 2005 03:53:38 - 1.197
+++ src/expr.c 20 Apr 2005 16:46:25 -
@@ -265,7 +265,7 @@
assert( pLeft->dyn==0 || pLeft->z[pLeft->n]==0 );
if( pLeft->dyn==0 && pRight->dyn==0 ){
pExpr->span.z = pLeft->z;
- pExpr->span.n = pRight->n + Addr(pRight->z) - Addr(pLeft->z);
+ pExpr->span.n = pRight->n + (pRight->z - pLeft->z);
}else{
pExpr->span.z = 0;
}
Index: src/main.c
===
RCS file: /sqlite/sqlite/src/main.c,v
retrieving revision 1.285
diff -u -r1.285 main.c
--- src/main.c 29 Mar 2005 23:34:58 - 1.285
+++ src/main.c 20 Apr 2005 16:46:25 -
@@ -623,8 +623,8 @@
static const short int totals[] =
{ 0, 1, 3, 8, 18, 33, 53, 78, 103, 128, 178, 228, 287};
# define NDELAY (sizeof(delays)/sizeof(delays[0]))
- ptr timeout = (ptr)Timeout;
- ptr delay, prior;
+ int timeout = *(int*)Timeout;
+ int delay, prior;
if( count <= NDELAY ){
delay = delays[count-1];
@@ -699,7 +699,7 @@
*/
int sqlite3_busy_timeout(sqlite3 *db, int ms){
if( ms>0 ){
-sqlite3_busy_handler(db, sqliteDefaultBusyCallback, (void*)(ptr)ms);
+sqlite3_busy_handler(db, sqliteDefaultBusyCallback, (void*));
}else{
sqlite3_busy_handler(db, 0, 0);
}
Index: src/sqliteInt.h
===
RCS file: /sqlite/sqlite/src/sqliteInt.h,v
retrieving revision 1.375
diff -u -r1.375 sqliteInt.h
--- src/sqliteInt.h 29 Mar
Re: [sqlite] SQLite on Motorola Power PC
Hi, Cem Vedat ISIK wrote: Thank you very much for your reply, I'm using gcc but I think I have nothing to do with a Mac, since the PowerPC I mention is not the PowerPC of Macintosh. I'm working on a Motorola PowerPC. Last time I checked, Motorola were one of the vendors delivering PowerPC chips to Apple's Macintosh line. That may have changed, of course. If you don't want to incur the expense of buying a hardware Mac, there is always software emulation. One Open Source PowerPC/Mac emulator which I'm very happy with is PearPC: http://pearpc.sourceforge.net http://www.pearpc.net You might get a cross-compiler to work more easily under that platform. PearPC supports networking, so you can probably even use something like Fink to get the required packages. If you don't want to buy Mac OS X, there is always OpenDarwin. The PearPC website has instructions for how to install OpenDarwin on PearPC. PearPC supports configurable sizes of RAM, so you shouldn't run into RAM problems using PearPC. HTH Ulrik Thomas Steffen wrote: On 4/18/05, Cem Vedat ISIK <[EMAIL PROTECTED]> wrote: Is there any information about How mant bytes of RAM does SQLite need to be compiled/built? I assume you are using gcc? Unfortunately gcc is known to have a big resource hunger. According to my experience, I would not try it with less than 64MB of RAM and 128MB of swap space. But that is for x86, the ppc version may be slightly different. What about using a Mac to compile it? I guess you would need to install Linux, because Mac OS doesn't know ELF, but then just about every PPC Mac should be able to compile SQLite. Thomas -- Ulrik Petersen, MA, B.Sc. University of Aalborg, Denmark Homepage: http://ulrikp.org
Re: [sqlite] SQLite on Motorola Power PC
Thank you very much for your reply, I'm using gcc but I think I have nothing to do with a Mac, since the PowerPC I mention is not the PowerPC of Macintosh. I'm working on a Motorola PowerPC. Thomas Steffen wrote: On 4/18/05, Cem Vedat ISIK <[EMAIL PROTECTED]> wrote: Is there any information about How mant bytes of RAM does SQLite need to be compiled/built? I assume you are using gcc? Unfortunately gcc is known to have a big resource hunger. According to my experience, I would not try it with less than 64MB of RAM and 128MB of swap space. But that is for x86, the ppc version may be slightly different. What about using a Mac to compile it? I guess you would need to install Linux, because Mac OS doesn't know ELF, but then just about every PPC Mac should be able to compile SQLite. Thomas --- Bu mesaj Karel MailScanner ile tehlikeli icerik ve virus kontrolunden gecirilmistir. KAREL A.S. - Bilgi Teknolojileri Bolumu This message has been scanned for viruses and dangerous content by Karel MailScanner, and is believed to be clean. KAREL A.S. - Information Technologies Department -- Cem Vedat ISIK [EMAIL PROTECTED] R Engineer Telecommunication Technologies KAREL ARGE CYBERPARK Cyberplaza B Blok Kat:3 Bilkent 06800 Ankara Turkey Tel: +90.312.265 02 90 Fax: +90.312.265 02 97
