Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sat, 11 Sep 2004, Darren Duncan wrote: At 12:49 AM +0100 9/12/04, Matt Sergeant wrote: This is just because Mac OSX is fussy - Linux won't complain and will let the latterly loaded symbol supercede. But it's a valid bug in DBD::SQLite2, so I'll fix it in the next release (should be simple). Matt. Now, unless you have a Mac OS X box of your own to test against, please send me a copy of the changed source files (the whole files, not diffs) asap, and I'll test your current distro with those changes. This way, if something else comes up, I can have tested that it works good prior to you uploading it to CPAN. I'll be waiting for them. -- Darren Duncan All DBD::SQLite dev is done on OS X (Panther currently). So it should be easy. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sun, 12 Sep 2004, Matt Sergeant wrote:
On Sat, 11 Sep 2004, Darren Duncan wrote:
At 12:49 AM +0100 9/12/04, Matt Sergeant wrote:
This is just because Mac OSX is fussy - Linux won't complain and will let
the latterly loaded symbol supercede. But it's a valid bug in
DBD::SQLite2, so I'll fix it in the next release (should be simple).
Matt.
Now, unless you have a Mac OS X box of your own to test against,
please send me a copy of the changed source files (the whole files,
not diffs) asap, and I'll test your current distro with those
changes. This way, if something else comes up, I can have tested
that it works good prior to you uploading it to CPAN. I'll be
waiting for them. -- Darren Duncan
All DBD::SQLite dev is done on OS X (Panther currently). So it should be
easy.
Ah, ok so Panther fixed the annoying strictness of Jaguar. However I think
the following patch should cover all bases:
Index: SQLite.xs
===
RCS file: /home/cvs/DBD-SQLite/SQLite.xs,v
retrieving revision 1.6
diff -u -r1.6 SQLite.xs
--- SQLite.xs 2004/07/21 20:50:42 1.6
+++ SQLite.xs 2004/09/12 10:02:30
@@ -37,7 +37,7 @@
SV *func
CODE:
{
-sqlite_db_create_function( dbh, name, argc, func );
+sqlite3_db_create_function( dbh, name, argc, func );
}
void
@@ -48,7 +48,7 @@
SV *aggr
CODE:
{
-sqlite_db_create_aggregate( dbh, name, argc, aggr );
+sqlite3_db_create_aggregate( dbh, name, argc, aggr );
}
int
@@ -56,7 +56,7 @@
SV *dbh
int timeout
CODE:
-RETVAL = sqlite_busy_timeout( dbh, timeout );
+RETVAL = dbd_set_sqlite3_busy_timeout( dbh, timeout );
OUTPUT:
RETVAL
Index: dbdimp.c
===
RCS file: /home/cvs/DBD-SQLite/dbdimp.c,v
retrieving revision 1.50
diff -u -r1.50 dbdimp.c
--- dbdimp.c2004/08/29 10:11:57 1.50
+++ dbdimp.c2004/09/12 10:02:30
@@ -128,7 +128,7 @@
}
int
-sqlite_busy_timeout ( SV *dbh, int timeout )
+dbd_set_sqlite3_busy_timeout ( SV *dbh, int timeout )
{
D_imp_dbh(dbh);
if (timeout) {
@@ -761,7 +761,7 @@
}
void
-sqlite_db_create_function( SV *dbh, const char *name, int argc, SV *func
)
+sqlite3_db_create_function( SV *dbh, const char *name, int argc, SV *func
)
{
D_imp_dbh(dbh);
int rv;
@@ -975,7 +975,7 @@
}
void
-sqlite_db_create_aggregate( SV *dbh, const char *name, int argc, SV
*aggr_pkg )
+sqlite3_db_create_aggregate( SV *dbh, const char *name, int argc, SV
*aggr_pkg )
{
D_imp_dbh(dbh);
int rv;
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
At 11:02 AM +0100 9/12/04, Matt Sergeant wrote: On Sun, 12 Sep 2004, Matt Sergeant wrote: All DBD::SQLite dev is done on OS X (Panther currently). So it should be easy. Ah, ok so Panther fixed the annoying strictness of Jaguar. However I think the following patch should cover all bases: Thank you. I applied those changes and all the install stuff worked. However, there are more outstanding, similar issues: [S0106000393c33758:Documents/Perl Distributions/devworld] darrenduncan% ../perl58 dbd_load_test.pl dyld: ../perl58 multiple definitions of symbol _sqlite_decode_binary /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite/SQLite.bundle definition of _sqlite_decode_binary /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite2/SQLite2.bundle definition of _sqlite_decode_binary Trace/BPT trap So it's good you're running this by me before a CPAN install. BTW, if you *really* can't access your own 10.2.8 machine, then I could probably give you temporary shell access on mine for remote testing. I await the next reply. -- Darren Duncan
[sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
Just now I installed the newest versions of DBD::SQLite v1.05 (3.06) and DBD::SQLite2 v0.33 (2.8.15). They both tested and installed with no problems, along with DBI v1.43 and Perl v5.8.5, all using GCC 3.3 on Mac OS X 10.2.8. However, this SQLite v2 and SQLite v3 can not be used simultaneously as they have symbol conflicts. The one flagged was _sqlite_busy_timeout, but from a quick scan of the offending files there seem to be more conflicts. It all looks like a number of 'sqlite' not being changed to 'sqlite3'. Since the libraries are dynamically linked, you only encounter the problem when trying to dynamically load both of them. Loading just one or the other is fine, doing them both results in an error, no matter which order they are loaded, following the second one. Below this email I give the exact error in a simplest reproduction case. I'm not sure if this problem is in the SQLite core or in the Perl bindings. Has anyone tried to dynamically link the cores both SQLite versions into the same single C program; did similar problems come up? Matt, please publish a newer DBD::SQLite as soon as you can get the pair to pass the following simple test without errors: use DBD::SQLite2; use DBD::SQLite;; that's also a good test for any subsequent releases. Note that I tried searching the source code for _sqlite_busy_timeout but that only appears in the .o files following compilation; I don't know what names in the source files correspond to those, since they obviously were transformed. Since I don't know whether the problem is in the core or in the Perl bindings, should I file a ticket on SQLite.org for this? Thank you. -- Darren Duncan -- [S0106000393c33758:Documents/Perl Distributions/devworld] darrenduncan% ../perl58 use DBD::SQLite2; use DBD::SQLite; dyld: ../perl58 multiple definitions of symbol _sqlite_busy_timeout /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite2/SQLite2.bundle definition of _sqlite_busy_timeout /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite/SQLite.bundle definition of _sqlite_busy_timeout Trace/BPT trap [S0106000393c33758:Documents/Perl Distributions/devworld] darrenduncan% ../perl58 use DBD::SQLite; use DBD::SQLite2; dyld: ../perl58 multiple definitions of symbol _sqlite_busy_timeout /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite/SQLite.bundle definition of _sqlite_busy_timeout /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite2/SQLite2.bundle definition of _sqlite_busy_timeout Trace/BPT trap
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Saturday 11 September 2004 3:19 pm, Darren Duncan wrote:
Just now I installed the newest versions of DBD::SQLite v1.05 (3.06)
and DBD::SQLite2 v0.33 (2.8.15). They both tested and installed with
no problems, along with DBI v1.43 and Perl v5.8.5, all using GCC 3.3
on Mac OS X 10.2.8.
However, this SQLite v2 and SQLite v3 can not be used simultaneously
as they have symbol conflicts.
I'm not seeing any such problem here. The following code works
perfectly with DBD::SQLite2 v0.33 and DBD::SQLite v1.05.
-
use DBI;
my $dbh = DBI-connect('dbi:SQLite2:dbname=popfile2.db','','') || die
$dbh-er
rstr;
my $dbh1 = DBI-connect('dbi:SQLite:dbname=popfile.db','','') || die
$dbh1-er
rstr;
my $sth=$dbh-prepare('select * from words limit 5;') || die $dbh-errstr;
$sth-execute() || die $dbh-errstr;
while (my $row = $sth-fetchrow_arrayref) {
print $row-[0] . \n;
}
$sth-finish();
$sth=$dbh1-prepare('select * from words limit 5;') || die $dbh1-errstr;
$sth-execute() || die $dbh1-errstr;
while (my $row = $sth-fetchrow_arrayref) {
print $row-[0] . \n;
}
$sth-finish();
$dbh-disconnect;
$dbh1-disconnect;
--
No errors, no problems.
Matt, please publish a newer DBD::SQLite as soon as you can get the
pair to pass the following simple test without errors: use
DBD::SQLite2; use DBD::SQLite;; that's also a good test for any
subsequent releases.
You don't 'use' the DBD modules, you use DBI; and it handles loading
of the modules specified in the connect.
Scott
--
POPFile, the OpenSource EMail Classifier
http://popfile.sourceforge.net/
Linux 2.6.5-7.108-default x86_64
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
At 4:05 PM -0700 9/11/04, Scott Leighton wrote:
I'm not seeing any such problem here. The following code works
perfectly with DBD::SQLite2 v0.33 and DBD::SQLite v1.05.
You don't 'use' the DBD modules, you use DBI; and it handles loading
of the modules specified in the connect.
Scott
I know how one normally invokes DBD modules. I only used them
directly in order to give the simplest test case. They originally
failed when I tried to open both using the normal DBI interface.
Here's a pared-down example of what I was actually trying. And this
did work before, when the only SQLite on the system was DBD::SQLite
0.31.
use strict; use warnings;
use DBI;
my @working_dbi_drivers = ();
foreach my $dbi_driver (DBI-available_drivers()) {
eval { DBI-install_driver( $dbi_driver ); }; $@ and next;
push( @working_dbi_drivers, $dbi_driver );
}
And the results:
[S0106000393c33758:Documents/Perl Distributions/devworld]
darrenduncan% ../perl58 dbd_load_test.pl
dyld: ../perl58 multiple definitions of symbol _sqlite_busy_timeout
/Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite/SQLite.bundle
definition of _sqlite_busy_timeout
/Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite2/SQLite2.bundle
definition of _sqlite_busy_timeout
Trace/BPT trap
The error messages are the same as before, which is the important
part. Perl dies hard; this isn't a trappable error.
Does the above code sample work on your machine?
-- Darren Duncan
P.S. The above code is part of a larger routine that auto-detects
what data sources are available via all DBI drivers. It calls
DBI-data_sources() for each driver that passes the load test.
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sat, 11 Sep 2004, Darren Duncan wrote: And the results: [S0106000393c33758:Documents/Perl Distributions/devworld] darrenduncan% ../perl58 dbd_load_test.pl dyld: ../perl58 multiple definitions of symbol _sqlite_busy_timeout /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite/SQLite.bundle definition of _sqlite_busy_timeout /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite2/SQLite2.bundle definition of _sqlite_busy_timeout Trace/BPT trap The error messages are the same as before, which is the important part. Perl dies hard; this isn't a trappable error. Does the above code sample work on your machine? This is just because Mac OSX is fussy - Linux won't complain and will let the latterly loaded symbol supercede. But it's a valid bug in DBD::SQLite2, so I'll fix it in the next release (should be simple). Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
At 12:49 AM +0100 9/12/04, Matt Sergeant wrote: This is just because Mac OSX is fussy - Linux won't complain and will let the latterly loaded symbol supercede. But it's a valid bug in DBD::SQLite2, so I'll fix it in the next release (should be simple). Matt. Now, unless you have a Mac OS X box of your own to test against, please send me a copy of the changed source files (the whole files, not diffs) asap, and I'll test your current distro with those changes. This way, if something else comes up, I can have tested that it works good prior to you uploading it to CPAN. I'll be waiting for them. -- Darren Duncan
