Found a problem in the Makefile.PL when attmepting to compile.
Looks like the patch for Oracle 10 XE
}
elsif ($mkfile = find_mkfile() and $mkfile =~ /\bdemo_xe.mk$/) { # Oracle XE
print "Looks like Oracle XE ($mkfile)\n";
fetch_oci_macros($mkfile);
$MK{CCINCLUDES} = '-I$(ICINCHOME)'; # undo odd refinition in demo_xe.mk
# From linux Oracle XE (10.2.0):
# ICINCHOME=$(ORACLE_HOME)/rdbms/public/
# ICLIBHOME=$(ORACLE_HOME)/lib/
# ICLIBPATH=-L$(ICLIBHOME)
# THREADLIBS=-lpthread [initially -lthread then redefined]
# CCLIB=$(ICLIBPATH) -lclntsh $(THREADLIBS)
# CCINCLUDES = -I$(ICINCHOME) [see above]
# CCFLAGS=$(CCINCLUDES) -DLINUX -D_GNU_SOURCE -D_REENTRANT -g
[initially without -DLINUX -D_GNU_SOURCE]
my $cclib = expand_mkvars($MK{CCLIB}, 0, 1);
my $ccflags = expand_mkvars($MK{CCFLAGS}, 0, 1);
$linkwith_msg = "$cclib";
$opts{LIBS} = [ $cclib ];
$opts{INC} = "-I$dbi_arch_dir $ccflags";
$opts{dynamic_lib} = { OTHERLDFLAGS => "$::opt_g" };
check_ldlibpthname();
}
causes the compile to fail when compiling for either instantclient 10.2 or
10.1
I commented out the code and the compile works fine. I am sure it is just a
case of getting the 'elsif' statment working correctly.
I should be able to get it working today.
Cheers
----- Original Message -----
From: "Tim Bunce" <[EMAIL PROTECTED]>
To: "Andy Hassall" <[EMAIL PROTECTED]>
Cc: <[email protected]>; "'Tim Bunce'" <[EMAIL PROTECTED]>
Sent: Friday, January 13, 2006 4:49 AM
Subject: Re: ANNOUNCE: DBD::Oracle 1.17 release candidate
> On Thu, Jan 12, 2006 at 10:42:36PM -0000, Andy Hassall wrote:
> > > Looking at the logs again it seems the picture isn't too bad...
> > >
> > > Note that the NLS_LANG=.AL32UTF8 tests pass. That's the
> > > config you ought to use.
> > >
> > > See the Unicode section in the DBD::Oracle docs for why
> > > Oracle's "UTF8"
> > > character set is broken and AL32UTF8 should be used instead.
> > >
> > > For the NLS_LANG=.WE8ISO8859P15 case you'll see that the unicode tests
> > > are being skipped on non-cygwin platforms, so the real bug is in the
> > > code that checks if the test should be run at all. They shouldn't.
> >
> > But tests like 22nchar_al32utf8 are failing, and only under Cygwin -
these
> > are "national" charset columns so should always be able to take Unicode
(at
> > least since 9i) - so shouldn't be skipped.
> >
> > Comparing two runs, cygwin vs. linux, both with:
> >
> > Database and client versions and character sets:
> > Database 10.2.0.1.0 CHAR set is WE8ISO8859P15 (Non-Unicode), NCHAR set
is
> > AL16UTF16 (Unicode)
> > Client 9.2.0.7 NLS_LANG is '.WE8ISO8859P15', NLS_NCHAR is '<unset>'
> >
> >
http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/linux_9207full_test102_WE8ISO
> > 8859P15_test.log
> >
> > t/22nchar_al32utf8......ok
> > t/22nchar_utf8..........ok
> >
> > The tests run on Linux and pass.
> >
> >
http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/cygwin_9207full_test102_WE8IS
> > O8859P15_test.log
> >
> > t/22nchar_al32utf8......
> > [ ... ]
> > Failed 2/37 tests, 94.59% okay
> > t/22nchar_utf8..........
> > [ ... ]
> > Failed 6/53 tests, 88.68% okay
> >
> > The same tests, same database, same NLS_LANG, fail under Cygwin.
> >
> > Unless I'm missing something! But that's why it looks a bit more
involved
> > to fix to me?
>
> You're probably right (I'm in skim mode at the moment). I suggest you
> first try to find and fix why the unicode tests are being run when they
> shouldn't (which may shed light on deeper issues), then we'll see what
> the remaining failures are.
>
> Tim.
>
