Skip Menu |

This queue is for tickets about the DBD-SQLite CPAN distribution.

Report information
The Basics
Id: 101573
Status: resolved
Priority: 0/
Queue: DBD-SQLite
People
Owner: Nobody in particular
Requestors: ppisar [...] redhat.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 1.46
Fixed in: (no value)

History Show all quoted text
  Fri Jan 16 09:26:40 2015 ppisar [...] redhat.com - Ticket created
Subject: Does not build with sqlite < 3070701: SQLite.xs:646: error: ‘SQLITE_OPEN_URI’ undeclared
sqlite 3070701 introduced SQLITE_OPEN_URI macro which is used in DBD-SQLite. Thus building DBD-SQLite against older sqlite fails: SQLite.xs: In function ‘XS_DBD__SQLite_OPEN_URI’: SQLite.xs:646: error: ‘SQLITE_OPEN_URI’ undeclared (first use in this function) SQLite.xs:646: error: (Each undeclared identifier is reported only once However Makefile.PL states oldest supported version is 3006000.
  Sat Jan 17 01:58:31 2015 ishigaki [...] cpan.org - Correspondence added
On Fri Jan 16 23:26:40 2015, ppisar wrote: Show quoted text
> sqlite 3070701 introduced SQLITE_OPEN_URI macro which is used in DBD- > SQLite. Thus building DBD-SQLite against older sqlite fails: > > SQLite.xs: In function ‘XS_DBD__SQLite_OPEN_URI’: > SQLite.xs:646: error: ‘SQLITE_OPEN_URI’ undeclared (first use in this > function) > SQLite.xs:646: error: (Each undeclared identifier is reported only > once > > However Makefile.PL states oldest supported version is 3006000.
Thanks for the heads-up. If you are interested in supporting older SQLite libraries, could you send me a patch/pull-request to add apporpriate sets of #ifdef SQLITE_VERSION_NUMBER >= ... #endif, and skip_all section in some of the tests?
  Sat Jan 17 01:58:31 2015 The RT System itself - Status changed from 'new' to 'open'
  Sat Jan 17 02:00:58 2015 ishigaki [...] cpan.org - Correspondence added
On Sat Jan 17 15:58:31 2015, ISHIGAKI wrote: Show quoted text
> On Fri Jan 16 23:26:40 2015, ppisar wrote:
> > sqlite 3070701 introduced SQLITE_OPEN_URI macro which is used in DBD- > > SQLite. Thus building DBD-SQLite against older sqlite fails: > > > > SQLite.xs: In function ‘XS_DBD__SQLite_OPEN_URI’: > > SQLite.xs:646: error: ‘SQLITE_OPEN_URI’ undeclared (first use in this > > function) > > SQLite.xs:646: error: (Each undeclared identifier is reported only > > once > > > > However Makefile.PL states oldest supported version is 3006000.
> > Thanks for the heads-up. > > If you are interested in supporting older SQLite libraries, could you > send me a patch/pull-request to add apporpriate sets of #ifdef > SQLITE_VERSION_NUMBER >= ... #endif, and skip_all section in some of > the tests?
Oops. Not #ifdef SQLITE_VERSION_NUMBER, but #if SQLITE_VERSION_NUMBER (or #ifdef <missing definition>), as you know.
  Mon Jan 19 08:27:07 2015 ppisar [...] redhat.com - Correspondence added
Subject: Re: [rt.cpan.org #101573] Does not build with sqlite < 3070701: SQLite.xs:646: error: ‘SQLITE_OPEN_URI’ undeclared
Date: Mon, 19 Jan 2015 14:26:52 +0100
To: Kenichi Ishigaki via RT <bug-DBD-SQLite [...] rt.cpan.org>
From: Petr Pisar <ppisar [...] redhat.com>
On Sat, Jan 17, 2015 at 01:58:37AM -0500, Kenichi Ishigaki via RT wrote: Show quoted text
> If you are interested in supporting older SQLite libraries, could you send > me a patch/pull-request to add apporpriate sets of #ifdef > SQLITE_VERSION_NUMBER >= ... #endif, and skip_all section in some of the > tests? >
While skipping the URI filename API is easy, this is not the only unconditionaly used API. There are vtables, status interface, and probably many more. I think the minimal version listed in the Makefile.PL is completly useless now. -- Petr
Download (untitled)
application/pgp-signature 213b

Message body not shown because it is not plain text.

  Mon Jan 19 10:20:14 2015 ishigaki [...] cpan.org - Correspondence added
On Mon Jan 19 22:27:07 2015, ppisar wrote: Show quoted text
> On Sat, Jan 17, 2015 at 01:58:37AM -0500, Kenichi Ishigaki via RT > wrote:
> > If you are interested in supporting older SQLite libraries, could you > > send > > me a patch/pull-request to add apporpriate sets of #ifdef > > SQLITE_VERSION_NUMBER >= ... #endif, and skip_all section in some of > > the > > tests? > >
> While skipping the URI filename API is easy, this is not the only > unconditionaly used API. There are vtables, status interface, and > probably > many more. > > I think the minimal version listed in the Makefile.PL is completly > useless now. > > -- Petr
I suppose you are trying to use an "intentionally disabled" code in Makefile.PL. As you see, it's not actively maintained (because it's disabled), and I usually don't care about it because I believe DBD::SQLite should always be used with the bundled SQLite library to keep things easy for us and downstream module maintainers, as it's quite tedious to check not only the version of DBD::SQLite and also the version of the SQLite library built and linked to it while doing something (most probably, while testing their modules). Historically speaking, 3.6.0 was called for because DBD::SQLite had explicitly depended on a C function introduced at that version, until recently. Now its usage is gone, DBD::SQLite may or may not compile with an older version than that (if patched appropriately). So I ask you again: do you need to support older libraries for whatever reasons? And up to which version do you want to support? As you might have seen, there are several #if SQLITE_VERSION_NUMBER blocks in dbdimp.c, added several years ago to let it compile with SQLite 3.6.0. If a patch to add more pops up (from you, or from someone else, maybe), I'm happy to apply it. If not, I'd rather leave it as is and just close this. I know there are several more to be fixed, but I suppose they are not too many.
  Tue Feb 10 03:25:01 2015 ishigaki [...] cpan.org - Correspondence added
On Tue Jan 20 00:20:14 2015, ISHIGAKI wrote: Show quoted text
> On Mon Jan 19 22:27:07 2015, ppisar wrote:
> > On Sat, Jan 17, 2015 at 01:58:37AM -0500, Kenichi Ishigaki via RT > > wrote:
> > > If you are interested in supporting older SQLite libraries, could > > > you > > > send > > > me a patch/pull-request to add apporpriate sets of #ifdef > > > SQLITE_VERSION_NUMBER >= ... #endif, and skip_all section in some > > > of > > > the > > > tests? > > >
> > While skipping the URI filename API is easy, this is not the only > > unconditionaly used API. There are vtables, status interface, and > > probably > > many more. > > > > I think the minimal version listed in the Makefile.PL is completly > > useless now. > > > > -- Petr
> > I suppose you are trying to use an "intentionally disabled" code in > Makefile.PL. As you see, it's not actively maintained (because it's > disabled), and I usually don't care about it because I believe > DBD::SQLite should always be used with the bundled SQLite library to > keep things easy for us and downstream module maintainers, as it's > quite tedious to check not only the version of DBD::SQLite and also > the version of the SQLite library built and linked to it while doing > something (most probably, while testing their modules). > > Historically speaking, 3.6.0 was called for because DBD::SQLite had > explicitly depended on a C function introduced at that version, until > recently. Now its usage is gone, DBD::SQLite may or may not compile > with an older version than that (if patched appropriately). > > So I ask you again: do you need to support older libraries for > whatever reasons? And up to which version do you want to support? > > As you might have seen, there are several #if SQLITE_VERSION_NUMBER > blocks in dbdimp.c, added several years ago to let it compile with > SQLite 3.6.0. If a patch to add more pops up (from you, or from > someone else, maybe), I'm happy to apply it. If not, I'd rather leave > it as is and just close this. I know there are several more to be > fixed, but I suppose they are not too many.
FYI, https://github.com/DBD-SQLite/DBD-SQLite/commit/eb10c7ce6f42cc91dd5c2072e8894387a2127172
  Tue Feb 10 03:25:07 2015 ishigaki [...] cpan.org - Status changed from 'open' to 'resolved'