Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 12:30 PM, Stephan Beal wrote: > On Fri, Jun 29, 2012 at 7:24 PM, Nico Williams wrote: > >> I'd be more concerned about linker symbol colliosions than about C >> pre-processor symbol collisions. >> > > We have since resolved it

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 7:24 PM, Nico Williams wrote: > I'd be more concerned about linker symbol colliosions than about C > pre-processor symbol collisions. > We have since resolved it - the current code can be compiled with and linked with both APIs in the same

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 9:27 AM, Stephan Beal wrote: > On Fri, Jun 29, 2012 at 4:25 PM, Richard Hipp wrote: > >> Bummer.  These are going to be hard to fix.  :-( >> > > i guessed that would be the case for some of the long-standing symbols like >

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 5:50 PM, Stephan Beal wrote: > caused by an unclosed /*, and the long-long (C++-specific) warning, but > other than that everything looks good as far as i'm concerned. > One more bit of pedanticness: lsmInt.h:35: #else # define LSM_DEBUG #endif

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 5:42 PM, Richard Hipp wrote: > I also had to change a couple of 7's to 8's in ctime.c (since "SQLITE_" is > 7 characters long whereas "SQLITE4_" is 8). But that plus your changes > above seem to do the trick. The changes are now checked in on the trunk.

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 11:08 AM, Stephan Beal wrote: > On Fri, Jun 29, 2012 at 4:38 PM, Stephan Beal > wrote: > > > Other than that i simply did s/sqlite3/sqlite4/g and all went just fine, > > so i wouldn't expect any problems with

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 4:38 PM, Stephan Beal wrote: > Other than that i simply did s/sqlite3/sqlite4/g and all went just fine, > so i wouldn't expect any problems with s/SQLITE_/SQLITE4_/g. > This actually works. Here's what i did (incrementally via trial/error), from

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 4:38 PM, Stephan Beal wrote: > Other than that i simply did s/sqlite3/sqlite4/g and all went just fine > One more tiny thing: the build flags for gcc should include -fPIC. Some Linuxes won't link against a lib built without -fPIC. -- -

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 4:33 PM, Richard Hipp wrote: > You think? You already need to do a global search/replace of "sqlite3_" to > "sqlite4_". How much harder is it to do a separate search/replace of > "SQLITE_" to "SQLITE4_"? > True enough. The only points which i came

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 10:32 AM, Stephan Beal wrote: > On Fri, Jun 29, 2012 at 4:30 PM, Richard Hipp wrote: > > > Maybe the thing to do is globally replace SQLITE_ with SQLITE4_? > > > > > That would be my preference, but it admittedly makes porting more

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 4:30 PM, Richard Hipp wrote: > Maybe the thing to do is globally replace SQLITE_ with SQLITE4_? > That would be my preference, but it admittedly makes porting more difficult, and i wouldn't cry too much if you decide to punt on this problem. i'm working

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 10:27 AM, Stephan Beal wrote: > On Fri, Jun 29, 2012 at 4:25 PM, Richard Hipp wrote: > > > Bummer. These are going to be hard to fix. :-( > > > > i guessed that would be the case for some of the long-standing symbols like >

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 4:27 PM, Stephan Beal wrote: > On Fri, Jun 29, 2012 at 4:25 PM, Richard Hipp wrote: > >> Bummer. These are going to be hard to fix. :-( >> > > i guessed that would be the case for some of the long-standing symbols > like

Re: [sqlite] symbol collisions between sqlite{3,4}.h

On Fri, Jun 29, 2012 at 4:25 PM, Richard Hipp wrote: > Bummer. These are going to be hard to fix. :-( > i guessed that would be the case for some of the long-standing symbols like SQLITE_OK. i will admit that including both 3 and 4 into one client is an odd corner-case. --

Re: [sqlite] symbol collisions between sqlite{3,4}.h

Bummer. These are going to be hard to fix. :-( On Fri, Jun 29, 2012 at 10:21 AM, Stephan Beal wrote: > Hi again, > > from sqlite4.h: > > _SQLITE3RTREE_H_ > > collides with sqlite3.h, causing ODR violations when both headers are > included (as is the case in my