Erwan Lemonnier wrote:
Hi Tim!
Ah, now it's getting interesting! :)
So I thought :)
Are the two versions of DBD::Oracle built against the same Oracle
version/installation?
No.
The one used by perl 5.6.2 was built against an oracle 9.2.1.0 (unsure
of the exact version, but it was a 9.*). The one used by perl 5.8.5
and perl 5.8.8 was built against an oracle 10.2.0.
What differences are there in the configuration of the two perl versions?
a diff between perl -V for my perl 5.6.2 and perl 5.8.8 shows the
following differences (the other options are in the 'perl -V' I
included in my very first post):
* 5.6.2:
osvers=2.6.9-42.0.2.elsmp
config_args='-Dprefix=/opt/perl-5.6.2'
useperlio=undef
ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
cppflags='-fno-strict-aliasing'
libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
ccdlflags='-rdynamic'
Compile-time options: USE_LARGE_FILES
* 5.8.8:
osvers=2.6.9-55.elsmp
config_args=''
useperlio=define
bincompat5005=undef
ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement
-I/usr/local/include'
libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
gnulibc_version='2.3.4'
ccdlflags='-Wl,-E'
Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO
Take a look at the source for the Perl_sv_2nv() function in sv.c
in the two distributions.
Also check for differences in the perl config
items that impact that code.
Damn. I had a bad feeling I would end up there.
Ok, I'll put on my deep dive googles and switch on the tolkien
translator. If you don't hear from me within a week, call the asylum
to fetch me ;)
Try it with:
my $v1 = "1.73696";
showbin($v1);
require DBD::Oracle;
my $v2 = "1.73696";
showbin($v2);
I get:
[HEAD] ~/HEAD/test/t/> !1030$ /opt/perl-5.6.2/bin/perl
02_test_require_dbd_oracle.t
0011111111111011110010101001011010010001101001110101110011010001
requiring
0011111111111011110010101001011010010001101001110101110011010001
[HEAD] ~/HEAD/test/t/> !1031$ /opt/perl-5.8.8/bin/perl
02_test_require_dbd_oracle.t
0011111111111011110010101001011010010001101001110101110011010001
requiring
0011111111111011110010101001011010010001101001110101110011010001
No difference. What triggered the problem happened during the connect,
but not during 'require DBD::Oracle'.
I know that on Solaris the act of loading the Oracle library (e.g.
libclntsh.so) could suck in other libraries which would cause
subtle side effects.
The particular case I (vagely) recall related to alarm(). Loading the
Oracle library caused the threaded version of alarm() to be loaded and
take precedence. So alarm(0) after loading DBD::Oracle wouldn't cancel
the alarm($timeout) set before loading it. Fun. I don't recall now
if/how that got resolved.
Anyway, I mention it because it seems like this is a similar issue.
Agggh. This example gives me goose flesh. I just hope I am not facing
something like that...
Is there anyone around with access to an oracle database 10.* and
running perl 5.8.* who could run the test code I provided earlier? The
one that just connects? It would be interesting to know how strongly
dependent it is to just my specific setup...
perl --version
This is perl, v5.8.8 built for i486-linux-gnu-thread-multi
select * from v$version
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
cat x.pl
use DBI;
sub showbin {
print "bin: ".unpack("B70",reverse pack("d",$_[0]))."\n";
}
my $v1 = "1.73696";
showbin($v1);
print "connecting\n";
my $DBC = DBI->connect("dbi:Oracle:XE",'XXX','YYY',
{ PrintError=>0, AutoCommit=>0 } );
my $v2 = "1.73696";
showbin($v2);
perl x.pl
bin: 0011111111111011110010101001011010010001101001110101110011010001
connecting
bin: 0011111111111011110010101001011010010001101001110101110011010000
Hope this helps.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
