I'm not entirely sure where the fault for this bug lies. I have a Web-based application that uses Class::DBI, DBI, and SQLite. It works fine. If I upgrade SQLite to 3.3.4, the application breaks, with errors of this form: FOF::Feeds can't SELECT f.uid,f.url,f.title,f.link,f.last_poll,f.desc,COUNT(i.uid) as total_items FROM feeds AS f,items AS i WHERE f.uid=i.feed GROUP BY f.uid ORDER BY f.title ASC: DBD::SQLite::st execute failed: not an error(21) at dbdimp.c line 398 [for Statement " SELECT f.uid,f.url,f.title,f.link,f.last_poll,f.desc,COUNT(i.uid) as total_items FROM feeds AS f,items AS i WHERE f.uid=i.feed GROUP BY f.uid ORDER BY f.title ASC"] at /usr/lib/perl5/vendor_perl/5.8.8/DBIx/ContextualFetch.pm line 52. at /var/www/localhost/htdocs/FOF/feeds.cgi line 29 Reverting to SQLite 3.2.7-r1 fixes the problem. I have tried recompiling DBD::SQLite, DBI, Class::DBI, and DBIx::ContextualFetch against the new SQLite, but that does not fix the problem. Googling the 'dbdimp.c' part of the error turns up a patch against DBD::SQLite 1.0.9, but I haven't gotten to the point of trying that out yet. Here's `emerge --info`: Portage 2.1_pre4-r1 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.6-r2, 2.6.15-gentoo-r4 i686) ================================================================= System uname: 2.6.15-gentoo-r4 i686 AMD Duron(tm) processor Gentoo Base System version 1.12.0_pre16 dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon -mtune=athlon -O3 -fomit-frame-pointer -ftracer -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon -mtune=athlon -O3 -fomit-frame-pointer -ftracer -fprefetch-loop-arrays -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ ftp://ftp.ndlug.nd.edu/pub/gentoo/ http://open-systems.ufl.edu/mirrors/gentoo http://gentoo.blueyonder.co.uk ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 pam elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LINGUAS
Added perl as it's their package
I think right now the problem is that the bundled version of sqlite that comes in dbd-sqlite is older than what you have on your system. sqlite (the app) is backwards compatible, but dbd-sqlite is still 'stuck' at 3.2.7. The maintainers of sqlite (the db :) have asked matt to update as of last week: http://rt.cpan.org/Public/Bug/Display.html?id=17571
(In reply to comment #2) > I think right now the problem is that the bundled version of sqlite that comes > in dbd-sqlite is older than what you have on your system. sqlite (the app) is > backwards compatible, but dbd-sqlite is still 'stuck' at 3.2.7. The maintainers > of sqlite (the db :) have asked matt to update as of last week: > http://rt.cpan.org/Public/Bug/Display.html?id=17571 I'm not sure I understand. The database in question was created with DBD::SQLite, and is only accessed via DBD::SQLite. I've got the 'sqlite' ebuild installed in case I need to do debugging, but I can reproduce this problem independently of the command-line 'sqlite' tool. That's part of what makes this so confusing -- given that DBD::SQLite _has_ the embedded SQLite, I'm not sure why the "stand-alone" SQLite ebuild being installed has any effect at all.
My understanding (possible wrong, I admit, but this is the impression i've been led to so far) is that the bundled sqlite is only invoked if you don't have a copy on your system. Since you in fact do have a copy on your system, DBD::SQLite is using the libraries contained there rather than anything it might have been bundled with -and hence the discprepancy, bad mojo, and all around breakage. I suspect upstream for DBD::SQLite will be correcting this shortly, soon as he gets to his rt bugs.
Just an update: I bought an x86_64 machine. The problem still happens there, and it still exists. 8^/=
(In reply to comment #5) > Just an update: I bought an x86_64 machine. The problem still happens there, > and it still exists. 8^/= > The original, actually filed bug, was that after upgrading from 3.2.7 of sqlite to 3.3.X of sqlite, dbd::sqlite failed to work. That is resolved as upstream, again see the posted link to rt on cpan. if you build a new box and put on it 3.3.x of sqlite, dbd::sqlite is still going to have the same problem.
Do ~dev-perl/DBD-SQLite-1.12 and ~dev-db/sqlite-3.3.5 work fine together? ,--Changelog | 1.12 | - Brought up to date with SQLite 3.3.5 '-- | My understanding (possible wrong, I admit, but this is the impression i've been | led to so far) is that the bundled sqlite is only invoked if you don't have a | copy on your system. Maybe the dependencies must be fixed then. If it uses the stand-alone sqlite it should be in the dependencies. ,--- Makefile.PL # Determine if we are going to use the provided SQLite code, or an already- # installed copy. To this end, look for two command-line parameters: # # USE_LOCAL_SQLITE -- If non-false, force use of the installed version # SQLITE_LOCATION -- If passed, look for headers and libs under this root # # In absense of either of those, expect SQLite 3.X.X libs and headers in the # common places known to Perl or the C compiler. '---
(In reply to comment #7) > Maybe the dependencies must be fixed then. If it uses the stand-alone sqlite it > should be in the dependencies. It's not a dependancy though. It's optional at best to have a copy of sqlite on your box before installing the perl module - its not a requirement, and so not listed in the deps.
(In reply to comment #8) > (In reply to comment #796) > > Maybe the dependencies must be fixed then. If it uses the stand-alone sqlite it > > should be in the dependencies. > > It's not a dependancy though. It's optional at best to have a copy of sqlite on > your box before installing the perl module - its not a requirement, and so not > listed in the deps. If sqlite is present it is linked in and it becomes a dependency. DBD::SQLite will break if sqlite will be removed afterwards. So sqlite becomes a dependency of DBD::SQLite. I see two possible ways here: always use the included code or always require sqlite being installed.
Perl team, how do you all suggest we proceed on this?
I lean against making sqlite a dep since it isn't (weak, I know). Even making it a dep doesn't solve the issues presented by tove in #9 - sqlite can still be upgraded or removed regardless of dbd-sqlite. That said, we do have an option or two in the module itself (that i really don't remember existing before). Chiefly we can either: # USE_LOCAL_SQLITE -- If non-false, force use of the installed version # SQLITE_LOCATION -- If passed, look for headers and libs under this root Personally, I prefer the former - keep the two kids apart, no dep breakage. anyone against that?
ok, went with the internal only for now. i've done a tree scan and doing this to the latest version of dbd-sqlite won't affect anything. We'll see how it goes from here and readdress if need be.
