Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

POD all the READMEs

  • Loading branch information...
commit cf76322a5db104fc3592bb9bd2348c5cd6722c91 1 parent bede864
@yanick authored
View
22 MANIFEST
@@ -9,18 +9,8 @@ Oracle.h
Oracle.xs
Oraperl.pm
README
-README-files/hpux/Makefile-Lincoln
-README.64bit.txt
-README.aix.txt
-README.clients.txt
README.help.txt
-README.hpux.txt
-README.java.txt
-README.macosx.txt
README.mkdn
-README.sec.txt
-README.win32.txt
-README.win64.txt
Todo
dbdimp.c
dbdimp.h
@@ -47,7 +37,16 @@ hints/svr4.pl
lib/DBD/Oracle.pm
lib/DBD/Oracle/GetInfo.pm
lib/DBD/Oracle/Object.pm
-lib/DBD/Oracle/Troubleshooting.pm
+lib/DBD/Oracle/Troubleshooting.pod
+lib/DBD/Oracle/Troubleshooting/Aix.pod
+lib/DBD/Oracle/Troubleshooting/Cygwin.pod
+lib/DBD/Oracle/Troubleshooting/Hpux.pm
+lib/DBD/Oracle/Troubleshooting/Linux.pod
+lib/DBD/Oracle/Troubleshooting/Macos.pod
+lib/DBD/Oracle/Troubleshooting/Sun.pod
+lib/DBD/Oracle/Troubleshooting/Vms.pod
+lib/DBD/Oracle/Troubleshooting/Win32.pod
+lib/DBD/Oracle/Troubleshooting/Win64.pod
mkta.pl
oci.def
oci8.c
@@ -90,5 +89,4 @@ t/80ora_charset.t
t/nchar_test_lib.pl
t/rt13865.t
t/rt74753-utf8-encoded.t
-test.pl
typemap
View
223 README-files/hpux/Makefile-Lincoln
@@ -1,223 +0,0 @@
-# makefile for rebuilding perl and all the modules we have built
-# or for rebuilding individual modules
-SHELL = /usr/bin/ksh
-CPAN_VERSION = 5.6.1
-FCCS_VERSION = fccs-03
-#needed for compatibility with ../build.mk:
-TOOL = perl
-PERL_VERSION = $(TOOL)-$(CPAN_VERSION)
-TOP = /opt/oss
-PERLDIR = $(PERL_VERSION)-$(FCCS_VERSION)
-PERL_ROOT = $(TOP)/pkg
-PREFIX = $(PERL_ROOT)/$(PERLDIR)
-#needed for compatibility with ../biuld.mk:
-VERSION = $(CPAN_VERSION)-$(FCCS_VERSION)
-
-MQS = MQSeries-1.14
-DBDORA = DBD-Oracle-1.12
-DBI = DBI-1.20
-EXPAT_VER = -1.95.2
-MQSERVER = 'PERL_CHANNEL/TCP/dsas105(1414)'
-
-MODULES = \
- libnet-1.0703 \
- Storable-0.7.2 \
- Time-HiRes-01.20 \
- Net-Daemon-0.35 \
- Digest-MD5-2.16 \
- Digest-SHA1-2.01 \
- Digest-HMAC-1.01 \
- MIME-Base64-2.12 \
- Net-DNS-0.19 \
- Mail-CheckUser-1.13 \
- Proc-Daemon-0.02 \
- Proc-Simple-1.14 \
- Openview-Message-0.01 \
- Business-CreditCard-0.26 \
- Data-UUID-0.06
-
-XML_PARSER = XML-Parser-2.31
-XML_MODULES = \
- XML-Simple-1.05 \
- XML-Generator-0.8
-#this does not behave same as 0.8
-#XML-Generator-0.91
-
-all: testOracleVar
- @banner ALL_PERL
- @echo "using perl PATH=$(PREFIX)/bin"
- ( export PATH=$(PREFIX)/bin:$$PATH && make perl )
- ( export PATH=$(PREFIX)/bin:$$PATH && make all_modules )
-
-print_macros:
- @echo TOOL=$(TOOL)
- @echo CPAN_VERSION=$(CPAN_VERSION)
- @echo PERL_VERSION=$(PERL_VERSION)
- @echo FCCS_VERSION=$(FCCS_VERSION)
- @echo PREFIX=$(PREFIX)
- @echo VERSION=$(VERSION)
- @echo PERLDIR=$(PERLDIR)
- @echo PERL_ROOT=$(PERL_ROOT)
-
-all_modules: modules xmlparser xml_modules dbi dbd mqs
-
-modules: testPath
- rm -rf $(MODULES)
- for m in $(MODULES); do \
- make module MODULE=$$m PREFIX=$(PREFIX) ; \
- done
-
-xml_modules: testPath
- rm -rf $(XML_MODULES)
- for m in $(XML_MODULES); do \
- make module MODULE=$$m PREFIX=$(PREFIX) ; \
- done
-
-dbi: testPath
- make module MODULE=DBI-1.20 PREFIX=$(PREFIX)
-
-dbd: testPath testOracleVar dbi touch.d/$(DBDORA).tch
-
-touch.d:
- mkdir touch.d
-
-xmlparser: touch.d/$(XML_PARSER).tch
-touch.d/$(XML_PARSER).tch: $(XML_PARSER).tar.gz
- tar -zxvf $(XML_PARSER).tar.gz
- ( cd $(XML_PARSER) && \
- perl Makefile.PL EXPATLIBPATH=$(TOP)/lib \
- EXPATINCPATH=$(TOP)/include && \
- make && \
- make test && \
- make install )
- rm -rf $(XML_PARSER)
- touch $@
-
-#chmod +w CONFIG;
-mqs_config:
- ( cd $(MQS); \
- mv CONFIG CONFIG.orig; \
- cp ../$$(uname).MQS.CONFIG CONFIG \
- )
-
-mqs_target:
- ( export MQSERVER=$(MQSERVER); \
- cd $(MQS) ;\
- make $(MQS_TARGET) \
- )
-
-mqs_build:
- ( export MQSERVER=$(MQSERVER); \
- cd $(MQS) ;\
- cp ../$$(uname).MQS.CONFIG ./CONFIG; \
- perl Makefile.PL; \
- make ; \
- )
-
-mqs: testPath /opt/mqm touch.d/$(MQS).tch
-touch.d/$(MQS).tch:
- @banner $(MQS)
- rm -rf $(MQS)
- gunzip -c $(MQS).tar.gz | tar -xvf -
- touch $(MQS)/.LICENSE.ACCEPTED
- make -s mqs_config
- make -s mqs_build
- make -s mqs_target MQS_TARGET=test
- make -s mqs_target MQS_TARGET=install
- touch $@
-
-
-touch.d/$(DBDORA).tch: testOracleVar
- @banner $(DBDORA)
- test ! -z "$(ORACLE_HOME)"
- -rm -rf $(DBDORA)
- gunzip -c $(DBDORA).tar.gz | tar -xf -
- cd $(DBDORA) ;\
- perl Makefile.PL; \
- make ; \
- make test ; \
- make install
- touch touch.d/$(DBDORA).tch
-
-
-perl: testVar $(PERL_VERSION) touch.d/$(PERL_VERSION).tch
-
-touch.d/$(PERL_VERSION).tch:
- @banner perl
- @if ls $(PREFIX) >/dev/null 2>&1 ; \
- then \
- echo "Error: Cannot install to an existing directory" ;\
- echo "Error: Please delete or move $(PREFIX)" ;\
- exit 1;\
- fi
- - cd $(PERL_VERSION); make distclean;
- cd $(PERL_VERSION); \
- ./Configure -Dprefix=$(PREFIX) -Ubincompat5005 -Uuselargefiles \
- -A eval:libswanted='\"cl pthread $$libswanted\" ' -des; \
- make ; \
- make test; \
- make install
- touch touch.d/$(PERL_VERSION).tch
-
-realclean distclean: clean_tch
- -rm -rf $(PERL_VERSION)
-
-clean: clean_tch
-clean_tch :
- -rm -f touch.d/*.tch
-
-module: touch.d/$(MODULE).tch
-
-touch.d/$(MODULE).tch :
- @banner $(MODULE)
- -rm -rf $(MODULE)
- gunzip -c $(MODULE).tar.gz | tar -xf -
- cd $(MODULE); \
- perl Makefile.PL </dev/null; \
- make test ; \
- if test -r Skipit_Makefile.aperl; then \
- make -f Makefile.aperl inst_perl MAP_TARGET=perl; \
- fi ;\
- make install
- rm -rf $(MODULE)
- touch touch.d/$(MODULE).tch
-
-$(PERL_VERSION):
- @if ls $(PREFIX) >/dev/null 2>&1 ; \
- then \
- echo "Error: Cannot install to an existing directory" ;\
- echo "Error: Please delete or move $(PREFIX)" ;\
- exit 1;\
- fi
- gunzip -c $(PERL_VERSION).tar.gz |tar xf -
- @echo "untar of perl is done"
-
-testVars: testVar testPath testOracleVar
-
-testVar: touch.d
- @echo "******** Building to: $(PREFIX) *********"
-
-testOracleVar:
- @if test -z "$$ORACLE_HOME" ; \
- then \
- echo " Please set \"export ORACLE_HOME=<value>\"" ;\
- exit 1; \
- else \
- echo ORACLE_HOME=$(ORACLE_HOME); \
- fi
- @if test -z "$$ORACLE_USERID" ; \
- then \
- echo " Please set \"export ORACLE_USERID=<username/password@dbname>\"" ;\
- exit 1; \
- else \
- echo ORACLE_USERID=$(ORACLE_USERID); \
- fi
-
-testPath:
- @if echo $$PATH | egrep -q '^$(PREFIX)/bin:'; then \
- echo PATH is OK; \
- else \
- echo "ERROR: You must have $(PREFIX)/bin first in your path as follows:" ;\
- echo " export PATH=$(PREFIX)/bin:\$$PATH" ;\
- exit 1; \
- fi
View
272 README.64bit.txt
@@ -1,272 +0,0 @@
-In general compiling DBD:Oracle for 64 bit machines has been a hit or miss operation.
-The main thing to remember is you will have to compile using 32 bit Perl and compile DBD::Oracle against a 32bit client
-which sort of defeats the purpose of having a 64bit box.
-So until 64bit Perl comes out we will be posing in this README any success stories we have come across
-
--------- Original Message --------
-
-Subject: Building 32bit DBD::Oracle against 64bit Oracle
-From: Dennis Reso
-Date: 7/9/2008 5:44 PM
-Priority: Normal
-
-Building DBD::Oracle v1.21 against Perl 5.8.5 Oracle 9.2.0.4 Solaris 8
-
-Got the dreaded "wrong ELF class" when the Oracle.so ends up built
-against the 64bit library instead of the one in $ORACLE_HOME/lib32.
-Use 'dump -vL Oracle.so' to see the internalized RPATH definition.
-
-Tried the following solution, widely posted, without success:
-
- perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/demo_rdbms32.mk
-
-What worked for me (pass the LIBDIR to the Oracle make process):
-
- export ORACLE_HOME=/apps/Oracle9.2.0.4
- export LD_LIBRARY_PATH=$ORACLE_HOME/lib32
- perl -pi -e 's/CC=true/CC=true LIBDIR=lib32/' Makefile.PL
- perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/demo_rdbms32.mk
- make
-
-The LIBDIR= is defined in $ORACLE_HOME/rdbms/lib/env_rdbms.mk which
-also includes a REDEFINES32= that overrides it, but is only used by
-the $ORACLE_HOME/rdbms/lib/ins_rdbms.mk. Oracle bug?
-
-Also repeated the same failure and success with
- Oracle 9.2.0.8 Solaris 10
- Oracle 10.2.0.3 Solaris 10
-
-Seems fixed in demo_rdbms32.mk (no Makefile.PL edit needed ) as of
- Oracle 10.2.0.4 Solaris 10
-
-Probably also fixed in some patchset newer than 9.2.0.4.
-
---
-Dennis Reso <dreso (at) comcast.net>
-
--------- Original Message --------
-
-Subject: DBD::Oracle 64-bit success story
-From: H.Merijn Brand
-Date: On Mon, 14 Apr 2008 09:48:41
-Priority: Normal
-
-I finally got round trying Oracle Instant Client on Linux with no
-Oracle installed, connecting to a 64bit Oracle 9.2.0.8 on HP-UX
-11.11/64. I had to do some fiddling with Makefile.PL (see bottom).
-Sorry for this being long. Feel free to mold it into anything useful.
-
-1. Before you start on DBD::Oracle, make sure DBD::ODBC works. That will
- assure your DSN works. Install unixODBC before anything else.
-
-2. Assuming you've got OIC from the rpm's, you will have it here:
-
- /usr/include/oracle/11.1.0.1/client
- /usr/lib/oracle/11.1.0.1/client
- /usr/share/oracle/11.1.0.1/client
-
-
-3. for the 64 bit clienat we have these rpm
- oracle-instantclient-basic-11.1.0.1-1.x86_64.rpm
- oracle-instantclient-devel-11.1.0.1-1.x86_64.rpm
- oracle-instantclient-jdbc-11.1.0.1-1.x86_64.rpm
- oracle-instantclient-odbc-11.1.0.1-1.x86_64.rpm
- oracle-instantclient-sqlplus-11.1.0.1-1.x86_64.rpm
-
- and to add to the confusement, they install to
-
- /usr/include/oracle/11.1.0.1/client64
- /usr/lib/oracle/11.1.0.1/client64
- /usr/share/oracle/11.1.0.1/client64
-
-4. To make DBD::ODBC work, I had to create a tnsnames.ora, and I chose
-
- /usr/lib/oracle/11.1.0.1/admin/tnsnames.ora
-
- /usr/lib/oracle/11.1.0.1/admin > cat sqlnet.ora
- NAMES.DIRECTORY_PATH = (TNSNAMES, ONAMES, HOSTNAME)
- /usr/lib/oracle/11.1.0.1/admin > cat tnsnames.ora
- ODBCO = (
- DESCRIPTION =
- ( ADDRESS_LIST =
- ( ADDRESS =
- ( PROTOCOL = TCP )
- ( PORT = 1521 )
- ( HOST = rhost )
- )
- )
- ( CONNECT_DATA =
- ( SERVICE_NAME = odbctest )
- )
- )
- /usr/lib/oracle/11.1.0.1/admin >
-
- Real world example changed to hide the obvious. Important bits are
- "ODBCO", which is the ODBC name, and it can be anything, as long as
- you use this in ORACLE_DSN too (please don't use whitespace, colons,
- semicolons and/or slashes. "rhost" is the hostname of where the DB
- is running, and "odbctest" is available on "rhost". To check that,
- run "lsnrctl services" on "rhost".
- Set the environment (TWO_TASK is not needed)
-
- > setenv LD_LIBRARY_PATH /usr/lib/oracle/11.1.0.1/client/lib
- > setenv TNS_ADMIN /usr/lib/oracle/11.1.0.1/admin
- > setenv ORACLE_HOME /usr/lib/oracle/11.1.0.1/client
- > setenv ORACLE_DSN dbi:Oracle:ODBCO
- > setenv ORACLE_USERID ORAUSER/ORAPASS
-
- Check if the connection works:
- > isql -v ODBCO
-
- And for Oracle:
- > sqlplus ORAUSER/ORAPASS@ODBCO
- and
- > sqlplus ORAUSER/ORAPASS@rhost/odbctest
-
- should both work
-
-
-Note by JPS:
-
-Merijn patched the trunk version of Makeifle.PL to account for the above it will be in release 1.22
-
--------- Original Message --------
-
-Subject: DBD::Oracle 64-bit success story
-From: "QiangLi" <qiangli@yorku.ca>
-Date: Thu, March 6, 2008 5:25 pm
-To: pause@pythian.com
-Priority: Normal
-
-hi,
-
-thanks for maintaining DBD::Oracle. I have installed DBD::Oracle against
- 64-bit oracle 10g on a 64-bit solaris machine. maybe worth another
-entry for the README.64bit.txt file.
-
-i am using gcc from sun freesoftware and also SUNWbinutils which
-contains the gas (gnu assembler)
-
-here is the steps with comment:
-
-# set install target
-% /usr/perl5/5.8.4/bin/perlgcc Makefile.PL PREFIX=/var/tmp/lib
-
-# since our perl is 32-bit, we can't build it against a 64bit oracle
-install.
-# edit Makefile and change reference to oracle's "lib/" to "lib32/"
-% perl -pi -e 's/oracle_home\/lib/oracle_home\/lib32/g' Makefile
-% perl -pi -e 's/oracle_home\/rdbms\/lib/oracle_home\/rdbms\/lib32/g'
-Makefile
-
-% make
-
-# ignore error like ORA-12162: TNS:net service name is incorrectly
-specified...
-% make test
-
-% make install
-
-# does it work.
-% perl -I'/var/tmp/lib/lib/site_perl/5.8.4/sun4-solaris-64int/'
--MDBD::Oracle -e1
-
-cheers,
-
-Qiang
-
-
-
-
--------- Original Message --------
-Subject: Tip: Compiling 32bit modules against 64bit Oracle 10g on solaris
-Date: Thu, 1 Nov 2007 16:41:28 -0400
-From: Edgecombe, Jason <jwedgeco@uncc.edu>
-To: <pause@pythian.com>
-CC: <cartmanltd@hotmail.com>
-
-
-
-Hi There,
-
-I just wanted to thank both of you.
-
-The tip from cartmanltd@hotmail.com was the trick for getting
-DBD::Oracle compiled in 32bit format against the Oracle 10g client on
-solaris.
-
-Here was the command that worked:
- perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/demo_rdbms32.mk
-
-Even though the tip was for aix, it fixed my build issue on solaris 9
-(sparc)
-
-I've been banging my head on this problem for a few days.
-
-Thanks,
-Jason
-
-Jason Edgecombe
-Solaris & Linux Administrator
-Mosaic Computing Group, College of Engineering
-UNC-Charlotte
-Phone: (704) 687-3514
-
-
-
-Source:Tom Reinertson
-Platform:Amd64
-OS:Gentoo-amd64
-
-The following instructions work for dbd::oracle 1.19 on a gentoo-amd64 installation.
-
-1) install the oracle libraries
-
- Strictly speaking you only need dev-db/oracle-instantclient-basic
- for dbd::oracle, but i always like to have sql*plus lying around,
- which requires the basic package, so i just install sql*plus.
-
- emerge dev-db/oracle-instantclient-sqlplus which also pulls in
- dev-db/oracle-instantclient-basic. these packages are fetch
- restricted so you will be required to follow the download instructions.
- following these instructions, you should have retrieved these packages:
-
- instantclient-basic-linux-x86-64-10.2.0.3-20070103.zip
- instantclient-sdk-linux-x86-64-10.2.0.3-20070103.zip
- instantclient-sqlplus-linux-x86-64-10.2.0.3-20070103.zip
-
- now move them into the /usr/portage/distfiles directory.
-
- you should now be able to emerge dev-db/oracle-instantclient-sqlplus.
-
-2) install DBD::Oracle
-
- issue the command:
-
- perl -MCPAN -e'install DBD::Oracle'
-
- this fails with the following error:
-
- x86_64-pc-linux-gnu-gcc: unrecognized option '-wchar-stdc++'
- x86_64-pc-linux-gnu-gcc: unrecognized option '-cxxlib-gcc'
- cc1: error: /ee/dev/bastring.h: No such file or directory
-
- find the offending files in your cpan directory:
- {~/.cpan/build/DBD-Oracle-1.19} grep -lr cxxlib *
- Makefile
- blib/arch/auto/DBD/Oracle/mk.pm
- mk.pm
-
- edit these files and remove the two invalid options and the include of bastring.h.
-
- now build the module:
-
- perl Makefile.PL -l
- make
- # make test generates lots of errors
- make test
- make install
-
- you should now be ready to run.
-
-
View
255 README.aix.txt
@@ -1,255 +0,0 @@
-
-DBD::Oracle AIX-specific README
-
-
-Using Visual Age 7 C Compiler
-======================================================================================
-
-- Oracle 9i is only certified as a 64-bit application on AIX 5L (5.1,5.2,5.3) with 32-bit support;
- in other words, there is no 9i "32-bit" Oracle client
-- Oracle 10g is certified as both a 64-bit application and a 32-bit Oracle client
-
-- This information only pertains to deploying
- the DBI (version 1.48)
- and DBD-Oracle (version 1.16):
- on AIX 5.3
- using Oracle 9i (9.2.0.1/9.2.0.5)
- using the existing Perl 5.8.2 (no custom-built Perl) which is 32-bit
- using Visual Age 7.0 C/C++ compiler
-
-Install the DBI (required for the DBD-Oracle install - no issues here)
-Untar the DBD-Oracle bundle
-Run Makefile.PL
-$ perl Makefile.PL
-Edit Makefile with following commands:
-1,$s?/lib/ ?/lib32/ ?g
-1,$s?-q64??g
-1,$s?/lib/sysliblist?/lib32/sysliblist?g
-Now perform normal commands to perform the testing/making:
-$ make
-$ make test
-$ make install
-
-I've tested the basics of the DBD-Oracle and it seems fully functional.
-
-Stephen de Vries
-paulhill20@copper.net
-
-
-
-Using gcc C Compiler
-======================================================================================
-
-
-
-DBD::Oracle with gcc and Oracle Instant Client on AIX
---------------------------------------------------------------------------------------
-Nathan Vonnahme Dec 15 2005, 4:28 pm Newsgroups: perl.dbi.users
-See: http://groups.google.com/group/perl.dbi.users/msg/0bd9097f80f2c8a9
-[ with updates 1/31/2006 - DBD::Oracle 1.17 doesn't need makefile hacking
-to work with instantclient on AIX ]
-
-
-Yes! It eluded me last year but I finally got DBD::Oracle working on an
-AIX machine using gcc. Here's the short version:
-
-First I had to recompile perl with gcc, using
- sh Configure -de -Dcc=gcc
-This apparently built a 32 bit perl, someday I will try getting it to go
-64 bit.
-
-I was then able to install and build DBI 1.50 with the CPAN shell.
-
-I downloaded the base and sdk packages of the Oracle Instant Client for
-AIX -- first I tried the 64 bit but that didn't work with my 32 bit perl
--- the 32 bit version (still at 10.1.0.3) did the trick. I unzipped
-them and moved the dir to /usr/local/oracle/instantclient10_1 and made a
-symlink without the version at /usr/local/oracle/instantclient , then
-set:
-
-export ORACLE_HOME=/usr/local/oracle/instantclient
-export LIBPATH=$ORACLE_HOME
-
-
-
-Oracle wasn't providing the sqlplus package for 32 bit AIX so I
-explicitly told Makefile.PL the version:
-
-perl Makefile.PL -V 10.1
-
-make
-
-My test databases were on other machines so I set these environment variables
-to get the tests to run:
-
-export ORACLE_DSN=DBI:Oracle://host/dbinstance
-export ORACLE_USERID="user/password"
-
-make test
-make install
-
-
-NOTE: I have an older full version of Oracle on this machine, and the
-ORACLE_HOME environment variable is normally set to point to that, so
-my perl scripts that use DBD::Oracle have to make sure to first set
- $ENV{ORACLE_HOME}='/usr/local/oracle/instantclient';
-
-
-
-
-
---------------------------------------------------------------------------------------
-The following setup worked to build on AIX 5.2:
-gcc-3.3.2 (32-bit) (configure opts [ --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as])
-Oracle-9.2.0 ( full install w/32bit support)
-perl-5.8.3 (built with above gcc/latest stable as of March 2004)
-Followed the directions from Rafael's email below, only set ORACLE_HOME, (and
-the appropriate test environmentals).
-1) build perl-5.8.3 with gcc
-2) install DBI
-3) ORACLE_HOME="your oracle home"
- ORACLE_USERID..
- ORACLE_SID ..
- (I ignored ORACCENV, didn't use it.)
-4) install DBD::Oracle, after perl Makefile.PL, edit the created Makefile,
-changing references to Oracle's ../lib to ../lib32. and change crt0_64.o to
-crt0_r.o. Remove the -q32 and/or -q64 options from the list of libraries to
-link with.
-5) make should be clean, make test should pass.
-This setup worked with 8.1.7 w/32 bit support, and with 9.2.0 w/ 32-bit support.
---Adrian Terranova
-peril99@yahoo.com
-
-
-
-
-Using xlc_r C Compiler
-======================================================================================
---------------------------------------------------------------------------------------
-From: Rafael Caceres <rcaceres@m1.aasa.com.pe>
-Date: 22 Jul 2003 10:05:20 -0500
-Message-Id: <1058886321.1066.13.camel@rcaceres.aasa.com.pe>
-
-The following sequence worked for me on AIX 5.1:
-
--use Perl 5.8.0 (the latest stable from CPAN)
-
--use the xlc_r version of IBM's compiler and build a 32 bit Perl
- (which xlc_r will do by default). All tests should be successful.
-
--get and install DBI
-
--get DBD::Oracle. Edit the Makefile.PL or Makefile for DBD::Oracle,
-changing references to Oracle's ../lib to ../lib32. and change crt0_64.o
-to crt0_r.o. Remove the -q32 and/or -q64 options from the list of
-libraries to link with. Do the make and make test.
-
--Set up the environment for making DBD::Oracle:
- ORACLE_HOME="your oracle home"
- ORACCENV = "xlc_r"
- ORACLE_USERID..
- ORACLE_SID ..
-
--Run make, all tests should be successfull -against Oracle 9.x at least.
-
-You should have no problems with Oracle 8.1.7, but accessing Oracle 7.x
-or previous is not possible (you'll core dump, or simply hang). The same
-goes for a Linux build or a Digital build, regarding access of different
-Oracle versions.
-
-Rafael Caceres
-
-On Tue, 2003-07-22 at 08:12, mpaladino@invacare.com wrote:
->
-> I dont believe I compiled Oracle. During the installation it was linked
-> but I am not sure it was compiled
->
-> I used a xlc compiler to compile PERL.
-> Got this message in the Perl Makefile.PL output
->
-> Warning: You will may need to rebuild perl using the xlc_r compiler.
-> You may also need do: ORACCENV='cc=xlc_r'; export ORACCENV
-> Also see the README about the -p option
->
-> this probobly means I need to rebuild PERL with xlc_r??
->
-> thanx
->
-> Mike Paladino
-> Database Administrator
-
-
-From: Rafael Caceres
->
-> Make sure you use the same compiler to build Oracle and Perl. We have
-> used xlc_r on Aix 5.1 with no problems. Your Perl build is 32 bit, so
-> when building DBD::Oracle, you should use the 32bit libraries (change
-> references to .../oracle/lib to .../oracle/lib32 in your Makefile).
-> Remove the references to the -q64 or -q32 parameters for ld in Makefile,
-> as they shouldn't be there.
->
-> Rafael Caceres
-
-
-From: "cartman ltd" <cartmanltd@hotmail.com>
-Subject: Tip for DBI and DBD::Oracle on AIX 5.1 and Oracle 9.2
-Date: Mon, 11 Aug 2003 18:15:38 +0000
-Message-ID: <BAY1-F58Temqpg2ItZe00032a0f@hotmail.com>
-
-Here is a tip for compiling DBD::Oracle as a 32 bit application on AIX 5.1
-64 bit and Oracle 9.2 64 bit without editting any makefiles. I hope people
-find this useful:
-
-First, the versions of products I used:
- DBI version 1.32
- DBD::Oracle version 1.14
- Oracle 9.2.0.2 - default 64 bit application with 32 bit libraries
- AIX 5.1 ML03 - 64 bit kernel - ships with Perl as a 32 bit application.
- VisualAge C/C++ 5.0.2
-
-Basically DBD must be compiled as 32 bit to link with Perl's 32 bit
-libraries.
- gunzip -c DBD-Oracle-1.14.tar.gz | tar xvf 
- cd DBD-Oracle-1.14
- perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/demo_rdbms32.mk
- make
-
-NB: I think there is a bug in the Oracle 9.2.0.3 file
-$ORACLE_HOME/rdbms/lib/env_rdbms.mk
-I corrected this (before running the above commands) by replacing the
-invalid linker option
- LDFLAGS32=-q32
-with
- LDFLAGS32=-b32
-
-Have fun: KC.
---------------------------------------------------------------------------------------
-
-Date: Wed, 30 Jun 2004 23:34:24 -0500
-From: "SCHULTZ, DARYLE (SBCSI)" <ds8183@sbc.com>
-
-Got it to work. Using dbd 1.16
-
-Perl 5.8.4 built like this, with Visual Age 6.0:
-
-config_args='-Dcc=xlc_r -Dusenm -Dprefix=/appl/datasync/work/perl5
--Dusethreads -Duse64bitall -des'
-==============================================
-
-Used DBI 1.42
-=============================================
-Added this to top of Oracle.h:
-#define A_OSF
-
-#include <oratypes.h>
-=======================
-Set LIBPATH to point to 64bit Oracle libs first.
-export LIBPATH=$ORACLE_HOME/lib:$ORACLE_HOME/lib32:/usr/lib
-
-Use: perl Makefile.PL -nob
-
-Change all references in Makefile of LD_RUN_PATH to be LIBPATH.
-Change nothing else, left all flags in Makefile, including -q64.
-Passed make, and all tests.
-
---------------------------------------------------------------------------------------
View
279 README.clients.txt
@@ -1,279 +0,0 @@
-This file contains some random notes relating to minimal Oracle
-configurations for building and/or using DBD::Oracle / Oraperl.
-
-
-*** ALL THE TEXT BELOW IS OLD ***
-*** THE PREFERED METHOD IS TO USE Oracle Instant Client ***
-
-
--------------------------------------------------------------------------------
-With recent versions of Oracle (specifically >= 7.3) you may be
-able to build DBD::Oracle without Pro*C installed by using the Oracle
-supplied oracle.mk file:
-
- perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/oracle.mk
-
-(The oracle.mk file might also be found in $ORACLE_HOME/rdbms/public/)
-
--------------------------------------------------------------------------------
-From: James Cooper <pixel@coe.missouri.edu>
-
-> [...], what do I need in addition to perl5 to access an Oracle database
-> on another system from a unix box (Solaris 2.5) that doesn't have an
-> oracle database running on it ?
->
-> In other words are their some oracle shared objects, etc. I need ?
-
-I don't have experience with Solaris, but on IRIX 5.3, I simply installed
-SQL*Net ($ORACLE_HOME/network/admin/*) and the OCI libraries which are in
-$ORACLE_HOME/lib. You'll also need the header files from
-$ORACLE_HOME/sqllib/public/*.h and $ORACLE_HOME/rdbms/demo/*.h (you won't
-need them all, but you can get rid of them after DBD::Oracle compiles).
-
-[You'll probably need at least ocommon in addition to network. But if you
-use the Oracle installer (as you always should) it'll probably install
-ocommon for you.]
-
-So just put that stuff on your client box and install DBI and DBD::Oracle
-there. Once DBD::Oracle is installed you can remove the OCI libraries and
-headers (make sure to keep SQL*Net!)
-
-Other than that, getting it working isn't too hard. If you're not
-familiar with SQL*Net, let me know. I'm no expert, but I know the basics.
-The main thing is to have a good tnsnames.ora file in
-$ORACLE_HOME/network/admin
-
--------------------------------------------------------------------------------
-From: Jon Meek <meekj@Cyanamid.COM>
-
-For my compilation of DBD-Oracle/Solaris2.5/Oracle7.2.x(x=2, I think), I
-just pulled the required files in the rdbms directory from the Oracle CD.
-The files I needed were:
-
-$ ls -lR
-drwxr-xr-x 2 oracle apbr 512 May 15 17:43 demo/
-drwxr-xr-x 2 oracle apbr 512 May 15 16:20 lib/
-drwxr-xr-x 2 oracle apbr 512 May 15 16:18 mesg/
-drwxr-xr-x 2 oracle apbr 512 May 15 17:38 public/
-
-./demo:
--r--r--r-- 1 oracle apbr 4509 Jun 29 1995 ociapr.h
--r--r--r-- 1 oracle apbr 5187 Jun 29 1995 ocidfn.h
--rw-rw-r-- 1 oracle apbr 6659 Jun 29 1995 oratypes.h
-
-./lib:
--rw-r--r-- 1 oracle apbr 1132 Jul 6 1995 clntsh.mk
--rwxr-xr-x 1 oracle apbr 5623 Jul 17 1995 genclntsh.sh*
--rw-r--r-- 1 oracle apbr 15211 Jul 5 1995 oracle.mk
--rw-r--r-- 2 oracle apbr 3137 May 15 16:20 osntab.s
--rw-r--r-- 2 oracle apbr 3137 May 15 16:20 osntabst.s
--rw-r--r-- 1 oracle apbr 9 May 15 16:19 psoliblist
--rw-r--r-- 1 oracle apbr 39 May 15 16:21 sysliblist
-
-./mesg:
--r--r--r-- 1 oracle apbr 183296 Jul 11 1995 oraus.msb
--r--r--r-- 1 oracle apbr 878114 Jul 11 1995 oraus.msg
-
-./public:
--r--r--r-- 1 oracle apbr 5187 Jun 29 1995 ocidfn.h
-
-Jon
-
--------------------------------------------------------------------------------
-Jon Meek <meekj@pt.Cyanamid.COM> Tue, 18 Feb 1997
-
-This was for Oracle 7.2.2.3.0 (client side for DBD:Oracle build) and
-SQL*net v2. I have heard that sqlnet.ora might not be needed.
-
-ls -lR oracle
-oracle:
-total 2
-drwxr-xr-x 3 meekj apbr 512 Nov 3 11:46 network/
-
-oracle/network:
-total 2
-drwxr-xr-x 2 meekj apbr 512 Nov 3 11:46 admin/
-
-oracle/network/admin:
-total 6
--rw-r--r-- 1 meekj apbr 309 Nov 3 11:46 sqlnet.ora
--rw-r--r-- 1 meekj apbr 1989 Nov 3 11:46 tnsnames.ora
-
--------------------------------------------------------------------------------
-
-From: Lack Mr G M <gml4410@ggr.co.uk>
-Date: Thu, 23 Jan 1997 18:24:03 +0000
-
- I noticed the appended in the README.clients file of the DBD-Oracle
-distribution. My experience is somewhat different (and simpler).
-
- On Irix5.3 (ie. what this user was using) I built DBI and DBD-Oracle
-on a system with Oracle and Pro*C installed. I tested it on another
-system (where I knew an oracle id). I installed it from a third (which
-had write rights to the master copies of the NFS mounted directories),
-but this didn't have Oracle installed.
-
- Having done this all of my systems (even those without a hint of
-oracle on them) could access remote Oracle servers by setting TWO_TASK
-appropriately. SQL*Net didn't seem to come into it.
-
- The dynamically-loadable library created (auto/DBD/Oracle/Oracle.so)
-contains no reference to any dynamic Oracle library.
-
- Exactly the same happened for my Solaris systems.
-
- From: James Cooper <pixel@coe.missouri.edu>
- > [...], what do I need in addition to perl5 to access an Oracle database
- > on another system from a unix box (Solaris 2.5) that doesn't have an
- > oracle database running on it ?
- >
- > In other words are their some oracle shared objects, etc. I need ?
-
-I don't have experience with Solaris, but on IRIX 5.3, I simply installed
-SQL*Net ($ORACLE_HOME/network/admin/*) and the OCI libraries which are in
-$ORACLE_HOME/lib. You'll also need the header files from
-$ORACLE_HOME/sqllib/public/*.h and $ORACLE_HOME/rdbms/demo/*.h (you won't
-need them all, but you can get rid of them after DBD::Oracle compiles).
-
-So just put that stuff on your client box and install DBI and DBD::Oracle
-there. Once DBD::Oracle is installed you can remove the OCI libraries and
-headers (make sure to keep SQL*Net!)
-
--------------------------------------------------------------------------------
-OS/Oracle version: Solaris 2 and Oracle 7.3
-
-Problem: DBD::Oracle works on the database machine, but not from remote
-machines (via TCP). SQL*Plus, however, does work from the remote machines.
-
-Cause: $ORACLE_HOME/ocommon/nls/admin/data/lx1boot.nlb is missing
-
-Solution: Make sure $ORACLE_HOME/ocommon is available on the remote machine.
-
-This was the first time I had used DBD::Oracle with Oracle 7.3.2. Oracle
-7.1 has a somewhat different directory structure, and seems to store files
-in different places relative to $ORACLE_HOME. So I just hadn't NFS
-exported all the files I needed to. I figured that as long as SQL*Plus
-was happy, I had all the necessary files to run DBD::Oracle (since that
-was always the case with 7.1). But I was wrong.
-
-James Cooper <pixel@organic.com>
-
--------------------------------------------------------------------------------
-Subject: Re: Oracle Licencing...
-Date: Thu, 15 May 1997 11:54:09 -0700
-From: Mark Dedlow <dedlow@voro.lbl.gov>
-
-Please forgive the continuation of this somewhat off-topic issue,
-but I wanted to correct/update my previous statement, and it's
-probably of interest to many DBD-Oracle users.
-
-> > In general, as I understand it, Oracle doesn't license the client runtime
-> > libraries directly, rather they get you for SQL*NET. It is typically
-> > about $100 per node. You have to have that licensed on any machine
-> > that runs DBD-Oracle.
-
-Oracle recently changed policy. sqlnet now comes with RDBMS licenses.
-If you have named RDBMS licenses, you can install sqlnet on as many
-client machines as you have named licenses for the server. If you
-have concurrent RDBMS licenses, you can install sqlnet on as many
-client machines as you like, and only use concurrently as many
-as you have concurrent server RDBMS licenses.
-
-OCI, Pro*C, et. al. only requires you to have a development license,
-per developer. The compiled apps can be distributed unlimited.
-The client where the client app resides must be licensed to use
-sqlnet, by the above terms, i.e. by virtue of what the licenses on
-the server are that the client is connecting to.
-
-This means one could legitimately distribute DBD-Oracle in compiled form.
-Probably not recommended :-)
-
-But is does mean one can compile DBD-Oracle and distribute it internally
-to your org without more licensing, as long as the targets have sqlnet.
-
-Obviously, this is not a legal ruling. I don't work for Oracle.
-But this is what my sales rep tells me as of today.
-
-Mark
--------------------------------------------------------------------------------
-
-From: Wintermute <wntrmute@gte.net>
-
-Ok, you may think me daft for this but I just figured out what was
-necessary in using DBI/DBD:Oracle on a machine that needs to access a
-remote Oracle database.
-
-What the docs tell you is that you just need enough of Oracle installed
-to compile it. They don't say that you need to keep that "just enough"
-around for the DBI to work properly!!
-
-So here's my predicament so that others might benefit from my bumbling.
-
-I needed to install Perl, DBI, and DBD:Oracle on a machine running a
-Fast Track web server (hostname Leviathan) that is to access a remote
-Oracle database (henceforth called Yog-Sothoth (appropriate for the
-beast that it is)). Leviathan doesn't have enough space for the 500M
-install that Oracle 7 for Solaris 2.5.1 wants so I had to figure out a
-way to get things done. Here's a brief list of the steps I took for
-Leviathan.
-
-1. Got the GCC binary dist for Solaris 2.6 and installed
-2. Got Perl 5.004_01 source/compiled/installed
-3. Got the DBI .90 compiled/installed
-4. Got DBD:Oracle...
-
- (and here's where it gets interesting).
-
- I exported the /opt/oracle7 directory from Yog-Sothoth to
-Leviathan in
-order to compile DBD:Oracle, then umount'ed it afterwards. Tried 'make
-test' after it had compiled and watched it flounder and fail. For the
-life of me I couldn't figure out why this could be so, so I went back
-and adjusted my TWO_TASK/ORACLE_USERID env vars.
- No luck.
- Wash/Rinse/Repeat.
- Still no luck.
-I started to get desperate about this time, so instead of screwing with
-it anymore I installed the module under the Perl heirarchy just to be
-done for the moment with it (figuring that the 'make test' script could
-be fallible). I neglected to mention that the errors I was getting were
-coming from the Oracle database on the remote machine, so I knew it
-worked in part, just not well enough to hold the connection for some
-reason.
-
-After having no luck with my own Perl connect script I tried remounting
-the nfs volume with Oracle on it and setting ORACLE_HOME to it. When I
-ran that very same Perl script it WORKED! Well sort of. None of the
-short connection methods worked, I was forced to use the long method of
-connecting IE: name/password@dbname(DESCRIPTION=(ADDRESS=(...etc.etc.
-
-So here I am figuring that I'm doing something right, but there's
-something I'm missing. Well it turns out that it's not me, it's the
-machine that's missing it. If you are going to be using the DBD:Oracle
-driver with DBI, you'll need more than just it after compile time,
-you'll need some Oracle files as well.
-
-(BTW I'm running Oracle 7.3.2.2.0)
-
-You'll need everything in /var/opt/oracle (on the machine that houses
-Oracle), as well as $ORACLE_HOME/ocommon/nls. Why National Language
-Support is needed I'll never know. ocommon/nls has to reside under the
-directory your $ORACLE_HOME points to, and it's best to leave
-/var/opt/oracle/'s path alone.
-
-When I made these adjustments on the Oracle'less box and tried the 'make
-
-test' again, it ran through without a hitch. I'll be doing some more
-intensive things with it from here on out and if anything changes I'll
-let you all know, however this seems odd that nothing is mentioned in
-the documentation about what residual files need to be around after
-compiling the DBD:Oracle for it to work successfully.
-
-Like I said, don't flame me for being stupid, but I just had to get this
-story off my chest since I've been puzzling over it all day and I feel
-that other people may want to do the same thing as I did, and will run
-into the same problems.
-
--- Wintermute
-
--------------------------------------------------------------------------------
View
133 README.help.txt
@@ -7,132 +7,6 @@ same or similar problems may exist on other systems or versions.
Most of this mess is due to Oracle's fondness for changing the
build/link process for OCI applications between versions.
--------------------------------------------------------------------------------
-Error: 'UV' not in typemap in Oracle.xs, line ...
-
-You're using Perl 5.5.3. Perl 5.5.3 is very old and and upgrading
-to at least 5.6.1 is recommended. The DBI itself has required
-perl >= 5.6.0 since DBI 1.38, August 2003.
-
-Meanwhile, edit Oracle.xs and change each UV to an IV, change newSVuv to newSViv,
-cross your fingers, and avoid using longer, bigger, wider than 2GB, or less than zero!
-This is a hacked DBD::Oracle and not recommended for production use.
-
--------------------------------------------------------------------------------
-If you get compiler errors refering to Perl's own header files
-(.../CORE/*.h) then there is something wrong with your installation.
-It is best to use a Perl that was built on the system you are trying to
-use and it's also important to use the same compiler that was used to
-build the Perl you are using.
-
--------------------------------------------------------------------------------
-Assorted runtime problems...
-
-Ensure that the version of Oracle you are talking to is the same one
-you used to build your DBD::Oracle module.
-
-Try building perl with 'usemymalloc' disabled.
-Try building perl with 'threads' enabled (esp for Oracle >= 8.1.6).
-
-Try removing "-lthread" from $ORACLE_HOME/lib/ldflags and/or
-$ORACLE_HOME/lib/sysliblist just for the duration of the DBD::Oracle build
-(but I can't really recommend this approach as it may cause subtle
-problems later)
-
-If you find a memory leak that you can isolate to DBD::Oracle, and you're
-using a perl built with threading enabled, first try rebuilding perl without
-support for threads. Apart from making perl run faster it may also fix the leak.
-Please report memory leaks, with a small self-contained test script,
-to dbi-users@perl.org.
-
--------------------------------------------------------------------------------
-Bad free() warnings:
-
-These are generally caused by problems in Oracle's own library code.
-You can use this code to hide them:
-
- $SIG{__WARN__} = sub { warn $_[0] unless $_[0] =~ /^Bad free/ }
-
-If you're using an old perl version (below 5.004) then upgrading will
-probably fix the warnings (since later versions can disable that warning)
-and is highly recommended anyway.
-
-Alternatively you can rebuild Perl without perl's own malloc and/or
-upgrade Oracle to a more recent version that doesn't have the problem.
-
--------------------------------------------------------------------------------
-Can't find libclntsh.so:
-
-Dave Moellenhoff <dmoellen@clarify.com>: libclntsh.so is the shared
-library composed of all the other Oracle libs you used to have to
-statically link.
-libclntsh.so should be in $ORACLE_HOME/lib. If it's missing, try
-running $ORACLE_HOME/lib/genclntsh.sh and it should create it.
-
-Also: Never copy libclntsh.so to a different machine or Oracle version.
-If DBD::Oracle was built on a machine with a different path to libclntsh.so
-then you'll need to set set an environment variable, typically
-LD_LIBRARY_PATH, to include the directory containing libclntsh.so.
-
-But: LD_LIBRARY_PATH is typically ignored if the script is running set-uid
-(which is common in some httpd/CGI configurations). In this case
-either rebuild with LD_RUN_PATH set to include the path to libclntsh
-or create a symbolic link so that libclntsh is available via the same
-path as it was when the module was built. (On Solaris the command
-"ldd -s Oracle.so" can be used to see how the linker is searching for it.)
-
-
--------------------------------------------------------------------------------
-Error while trying to retrieve text for error ...:
-
-From Lou Henefeld <LHenefeld@gnn.com>: We discovered that we needed
-some files from the $ORACLE_HOME/ocommon/nls/admin/data directory:
- lx00001.nlb, lx10001.nlb, lx1boot.nlb, lx20001.nlb
-If your national language is different from ours (American English),
-you will probably need different nls data files.
-
-
--------------------------------------------------------------------------------
-ORA-01019: unable to allocate memory in the user side
-
-From Ethan Tuttle <etuttle@ipro.com>: My experience: ORA-01019 errors
-occur when using Oracle 7.3.x shared libraries on a machine that
-doesn't have all necessary Oracle files in $ORACLE_HOME.
-
-It used to be with 7.2 libraries that all one needed was the tnsnames.ora
-file for a DBD-Oracle client to connect. Not so with 7.3.x. I'm not sure
-exactly which additional files are needed on the client machine.
-
-Furthermore, from what I can tell, the path to ORACLE_HOME is resolved and
-compiled into either libclntsh.so or the DBD-Oracle. Thus, copying a
-minimal ORACLE_HOME onto a client machine won't work unless the path to
-ORACLE_HOME is the same on the client machine as it is on the machine
-where DBD-Oracle was compiled.
-
-ORA-01019 can also be caused by corrupt Oracle config files such as
-/etc/oratab.
-
-ORA-01019 can also be caused by using a different version of the
-message catalogs ($ORACLE_HOME/ocommon/nls/admin/data) to that used
-when DBD::Oracle was compiled.
-
-Also try building with oracle.mk if your DBD::Oracle defaulted to proc.mk.
-
--------------------------------------------------------------------------------
-SCO - For general help enabling dynamic loding under SCO 5
-
- http://www2.arkansas.net/~jcoy/perl5/
-
--------------------------------------------------------------------------------
-AIX - warnings like these when building perl are not usually a problem:
-
-ld: 0711-415 WARNING: Symbol Perl_sighandler is already exported.
-ld: 0711-319 WARNING: Exported symbol not defined: Perl_abs_amg
-
-When building on AIX check to make sure that all of bos.adt (13 pieces)
-and all of bos.compat (11 pieces) are installed.
-
-Thanks to Mike Moran <mhm@austin.ibm.com> for this information.
-------------------------------------------------------------------------------
AIX 4 - core dump on login and similar problems
@@ -376,13 +250,6 @@ Try each of these in turn (follow each with a make && make test):
perl Makefile.PL -n LIBCLNTSH
let me know if any of these help.
--------------------------------------------------------------------------------
-Some runtime problems might be related to perl's malloc.
-
-This is a long shot. If all else fails and perl -V:usemymalloc says
-usemymalloc='y' then try rebuilding perl using Configure -Uusemymalloc.
-If this does fix it for you then please let me know.
-
===============================================================================
Hang during "repetitive connect/open/close/disconnect" test:
View
322 README.java.txt
@@ -1,322 +0,0 @@
-README.java.txt
-
-This file relates to a specific problem on Solaris platforms
-for Oracle 8.1.6 (and possibly later versions) where loading
-DBD::Oracle fails with an error message like:
-
- ``You must install a Solaris patch to run this version of
- the Java runtime.
- Please see the README and release notes for more information.''
-
-The problem seems to be that:
-
-1/ By default, the Oracle shared library contains a ``Radius
- authentication module'' that is implemented in Java.
-2/ The Java implementation requires that the thread library is
- also linked into the application.
-3/ For some inexplicable reason the thread library has to be
- linked to the executable that's doing the dynamic loading.
- It's is not sufficient to link -lthread to DBD::Oracle.
-
-There are several ways to workaround this:
-
-1/ Remove the Radius authentication module if you don't need it.
- This requires you to perform surgery on the Oracle installation.
- (If the name Radius doesn't mean anything to you and you're
- the person maintaining the Oracle installation then you almost
- certainly don't need it.)
-
-2/ Use the LD_PRELOAD environment variable to force the pre-loading
- of the thread library. Note that this must be set before perl
- starts, you can't set it via $ENV{LD_PRELOAD} within the script.
-
-3/ Link the thread library to your perl binary.
- You can do that either by (re)building perl with thread support
- or, I believe, it should be possible to issue a magic 'ld' command
- to add linkage to the thread library to an existing perl executable.
- (But you'll need to work that one out yourself. If you do please let
- me know so I can add the details here to share with others.)
-
-Most of this information comes from Andi Lamprecht, to whom I'm very
-grateful indeed.
-
-I've included below two of his email messages, slightly edited, where
-he explains the procedure for options 1 and 2 above. I've also
-appended a slight reworking of option 1 from Paul Vallee. And I've later
-added some more useful messages from other people.
-
-Tim.
-
-----
-
-
-From: andi@sunnix.sie.siemens.at
-
-Have managed it to get DBD to work with Oracle 8i without these nasty Java
-error! It seems to be that a thing called "NAU" links in a radius
-athentication module which is written in Java and this causes the
-additional java libraries in the libclntsh.so. After throwing it all out
-DBD tests ran successfully.
-
-The steps to take are:
-
- - shut down Oracle server if you have one running in the installation
- you're about to modify.
- - take a backup copy of your Oracle installation! You have been warned!
-
- - go to $ORACLE_HOME/network/lib (or it maybe (also?) in $ORACLE_HOME/oas/lib)
- - rebuild nautab.o with:
-
- make -f ins_nau.mk NAU_ADAPTERS="IDENTIX KERBEROS5 SECURID" nautab.o
-
- This build a new nautab.o without the radius authentication module.
-
- - go to $ORACLE_HOME/lib
- - edit file "ldflags" and delete all occurences of "-lnrad8" and "-ljava"
- and "-[LR]$ORACLE_HOME/JRE/lib/sparc/native_threads"
-
- - go to $ORACLE_HOME/bin
- - build a new libclntsh.so with:
-
- genclntsh
-
- - start up Oracle
-
- - go back to the DBD-* directory and build the Oracle driver with:
-
- perl Makefile.PL; make; make test
-
-This worked for me, the database is still operational, MAYBE SOME JAVA
-STUFF ISN'T WORKING. Better someone else with more experience in java
-finds out ...
-
-The problem seems to be a dynamic linking issue. Whenever java virtual
-machine is loaded, some symbols are missing (with java 1.2.2_05 these
-_thread_something symbols where not found, even with linked-in
-libthread.so, with java 1.1.8 some _lseek or so symbols couldn't be
-resolved). Seems Oracle did a good job in integration of Java in the
-database ...
-
-Ok, should go out now 'cause its a beatiful wheater here in Vienna!
-
-Greetings
-A. Lamprecht
-
------------
-
-
-From: andi@sunnix.sie.siemens.at
-
-For some reason libthread.so.1 isn't included as dynamic object in perl
-binary and so symbols aren't found.
-
-The interesting output of LD_DEBUG=symbols:
-symbol=thr_getstate; dlsym() starting at file=/usr/local/bin/perl
-symbol=thr_getstate; lookup in file=/usr/local/bin/perl [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libsocket.so.1 [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libnsl.so.1 [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libdl.so.1 [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libm.so.1 [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libc.so.1 [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libcrypt_i.so.1 [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libmp.so.2 [ ELF ]
-symbol=thr_getstate; lookup in file=/lib/libgen.so.1 [ ELF ]
-ld.so.1: /usr/local/bin/perl: fatal: thr_getstate: can't find symbol
-
-This list looks exactly like the one you get when ldd-ing the perl binary.
-There is an option to the dynamic linker "LD_PRELOAD" and if you set it with
-
- LD_PRELOAD=/lib/libthread.so.1
- export LD_PRELOAD
-
-before starting any DBD::oracle app, the app works! (Note that this must
-be set before perl starts, you can't set it via $ENV{LD_PRELOAD} within
-the script.)
-
-It looks like after libjava and libjvm is loaded, the library search path
-is somehow stripped to the one of the perl binary ...
-
-[That looks like a Solaris bug]
-
-Hope this helps.
-
-A. Lamprecht
------------
-
-
-From: Paul Vallee <vallee+dbi@pythian.com>
-
-Andi is right. Three cheers for Andi!!! :-)
-
-Final Summary (this is mostly Andi's work summarized here)
-
-1. Copy your ORACLE_HOME in it's entirety to a new directory.
-cp -r $ORACLE_HOME $ORACLE_HOME.nojava
-
-2. Set your ORACLE_HOME variable to the new one. Save the old one for reference.
-export OLD_ORACLE_HOME=$ORACLE_HOME
-export ORACLE_HOME=$ORACLE_HOME.nojava
-
-3. cd $ORACLE_HOME/network/lib (or it maybe (also?) in $ORACLE_HOME/oas/lib)
-This is your new ORACLE_HOME - the temporary one that will soon be without
-Java or Radius.
-
-4. build nautab.o with
-make -f ins_nau.mk NAU_ADAPTERS="IDENTIX KERBEROS5 SECURID" nautab.o
-
-5. go to $ORACLE_HOME/lib
-edit file "ldflags" and delete all occurences of "-lnrad8" and "-ljava"
-and "-[LR]$ORACLE_HOME/JRE/lib/sparc/native_threads"
-I wrote this little pipeline to do this.
-sed 's/-lnrad8//g' < ldflags | \
-sed 's/-ljava//g' | \
-sed "s%-L$OLD_ORACLE_HOME/JRE/lib/sparc/native_threads%%g" | \
-sed "s%-R$OLD_ORACLE_HOME/JRE/lib/sparc/native_threads%%g" | > newldflags
-If you look at newldflags, and like it, then run:
-cp ldflags oldldflags; cp newldflags ldflags
-
-6. go to $ORACLE_HOME/bin and build a new libclntsh.so with "genclntsh"
-genclntsh
-
-7. go to your DBD::oracle install directory and go through the regular
-install process.
-perl Makefile.PL; make; make install
-(I find the make test less useful than my test.pl perl file.)
-
-8. Set LD_LIBRARY_PATH=$ORACLE_HOME/lib.
-This part is very important - remember that at this stage ORACLE_HOME is set
-to the nojava home. Make this permanent by explicitly setting
-LD_LIBRARY_PATH to the nojava lib directory in your .profile.
-This is the step that stalled me - thanks again to Andi.
-
-9. Test this out. I use the following command which fails
-nicely if we've failed, and is very quiet if we've succeeded:
- perl -MDBD::Oracle -e 0
-there should be no output. Congratulations.
-
-10. Get rid of everything other than libclntsh.so in your new ORACLE_HOME -
-the rest is a waste of space.
-cd $ORACLE_HOME; cd ..
-mv $ORACLE_HOME $ORACLE_HOME.rmme
-mkdir $ORACLE_HOME; mkdir $ORACLE_HOME/lib
-cp $ORACLE_HOME.rmme/lib/libclntsh.so $ORACLE_HOME/lib
-
-11. Run test.pl again just to be sure it still works.
-
-12. If test.pl is still working, then we can reclaim space with
-rm -fr $ORACLE_HOME.rmme
-
-Note that in my opinion this is a workaround - there is no reason on the
-face of it that I can fathom that we shouldn't be able to use DBD::Oracle to
-connect to Oracle with Java compiled in. (?)
-
-Enjoy,
-Paul Vallee
-Principal
-The Pythian Group, Inc.
-------------------------------------------------------------------------------
-
-From: Peter Ludemann <peter.ludemann@us.xacct.com>
-
-Here's a different way for ensuring that LD_PRELOAD has been set:
-
- unless (($ENV{LD_PRELOAD}||'') =~ /thread.so/) {
- $ENV{LD_PRELOAD} = '/lib/libthread.so';
- exec($^X, '-w', $0, @ARGV);
- }
-
-This hasn't been rigorously tested, but it seems to do the trick, at
-least on Solaris 7 with Oracle 8.
-
-------------------------------------------------------------------------------
-
-From: VG <vgabriel@nbcs.rutgers.edu>
-
-I've had luck with adding the following at the top of my program:
-
-use DynaLoader;
-Dynaloader::db_load_file("/usr/lib/libthread.so", 0x01);
-
-(Others have reported this nor working for them.)
-
-------------------------------------------------------------------------------
-
-From: daver@despair.tmok.com (Dave C.)
-Subject: Re: DBI::DBD with Oracle 8i
-Newsgroups: comp.lang.perl.modules
-
-It looks like a lot of people are having this problem....
-
-I managed to solve it. I'm running Oracle 8.1.6, Solaris 8, Perl 5.6.0,
-and the latest DBI/DBD modules.
-
-I did some experimentation and discovered that the root of the problem
-was that libclntsh.so was linking with nautab.o. For some reason,
-nautab.o was linked with this RADIUS authentication (?) thing that was
-calling into Java (even though I don't use that particular functionality.)
-
-So, what I had to do was generate a libclntsh.so that linked with a
-nautab.o that didn't require the radius (and thus the java). I then
-forced the Oracle DBD to link with my library and installed it, and it
-worked.
-
-Here's the step-by-step:
-
-To do this, first copy the "genautab" and "genclntsh" scripts to a
-scratch directory. By default "genautab" apparently generates some
-default network authentication stub without a lot of options (which was
-okay for me.)
-
-I ran:
-
- ./genautab >nautab.s
- as -P nautab.s
-
-After this step you should have a "nautab.o" file.
-
-Now, you must must modify "genclntsh" to produce your custom clntsh
-library (which I called "perlclntsh" so I wouldn't mess up the original
-Oracle library.) So I went into the file and modified CLNT_NAM to read
-"perlclntsh". I also changed LIB_DIR to put the resulting library in
-my current directory: (LIB_DIR=`pwd`)
-
-Also, instead of creating the library, I modified the script to just
-echo the command. Search for "# Create library" and put "echo " before
-{$LD} ${LD_RUNTIME}... Now, when you run "./genclntsh" you should get
-a large command. Redir this command to a file "./genclntsh >t"
-
-Now, edit this file and remove all references to java libraries (get
-rid of all "-ljava" instances, at least, and you may need to delete
-other stuff, like -lnative_threads.) . Run your script: "sh ./t".
-After some time you should wind up with a "libperlclntsh.so.8.0".
-This is your custom library any of the java stuff linked in.
-
-Then copy this lib to /usr/local/lib and create a softlink
-"libperlclntsh.so" to "libperlclntsh.so.8.0" (or copy it wherever you
-want...)
-
-Then you have to force DBD to link with this library instead of linking
-with the libclntsh.so provided by Oracle.
-
-Basically what I did was follow the normal DBD-Oracle directions. I
-then edited the resulting Makefile manually and changed all references
-of libclntsh.so to libperlclnt.so (ie, -lclntsh to -lperlclntsh) I
-also changed the LDDLFLAGS and LDFLAGS and appended "-L/usr/local/lib
--R/usr/local/lib -L/usr/ucblib -R/usr/ucblib -lucb". (for some reason
-the resulting DBD wanted to link with ucb) Run "make" and rebuild the
-DBD. Now "make test" should pass.
-
-Note that this was a fairly long (couple of hours) series of trial and
-error before I finally got this to work. Your system may be different
-and you may encounter your own linking problems, etc.
-
-Disclaimer: This may not work for you, but it worked for me. Even if it
-does work for you there is no guarantee that the resulting module will
-function correctly and won't hose your database, etc...
-
-I forgot to mention that in script resulting from genclntsh you must
-tell it to use _your_ nautab.o for linking, not the oracle lib one.
-Oops.
-
--Dave
-
View
142 README.sec.txt
@@ -1,142 +0,0 @@
-I have no intention of becoming a channel for Oracle Support Services
-but this is a significant security hole and so I'm making an exception.
-
------ Forwarded message from Oracle Support Services <MEDIAGRP@US.ORACLE.COM> -----
-
-Date: Fri, 7 May 1999 06:29:09 -0700
-From: Oracle Support Services <MEDIAGRP@US.ORACLE.COM>
-Subject: SUID Security Issue
-
-Platform: UNIX
-
-Distribution: Internal & External
-
-Problem Subject Line: SUID Security
-
-Product: Oracle Enterprise Manager 2.0.4
- Oracle Data Server
-
-Oracle Version: 8.0.3, 8.0.4, 8.0.5, 8.1.5
-
-Component: Intelligent Agent
- Oracle Data Server
-
-Component Version: 8.0.3, 8.0.4, 8.0.5, 8.1.5
-
-Sub-Component: N/A
-
-Platform Version: All Unix Versions.
-
-Errors: N/A
-
-Revision Date: 6-March-1999
-
-Problem Description:
-
-On UNIX platforms, some executable files have the setuid (SUID)
-bit on. It may be possible for a knowledgeable user to use
-these executables to bypass your system security by elevating
-their operating system privileges. Oracle Corporation has
-identified issues regarding executables with SUID set in
-Oracle releases 8.0.3, 8.0.4, 8.0.5 and 8.1.5 on UNIX platforms
-only. This problem will be fixed in Oracle releases 8.0.6 and
-8.1.6.
-
-Depending on your Oracle installation, the available patch will 1)
-correct the SUID bits on applicable files, and/or 2) delete the
-oratclsh file. This shell script should be run immediately, and also
-should be run after each relink of Oracle.
-
-You can download the patch from Oracle Support?s MetaLink website by
-going to the following URL,
-http://support.oracle.com/ml/plsql/mlv15.frame?call_type=download&javaFlag=JAVA.
-Once you are in this page, select 'Oracle RDBMS' as the product
-and then click on the 'Go' button. Then download patch named 'setuid.'
-
-Please contact Oracle Worldwide Support for any additional issues.
-
------ End forwarded message -----
-
-Date: Sat, 08 May 1999 19:12:52 -0700
-From: Mark Dedlow <dedlow@voro.lbl.gov>
-
-I went to the URL listed for the patch, but it appears you can't get to
-it directly. It requires a Oracle Metalink account, and even then, you
-have to follow a bunch of links to get it, you can't go direct (at
-least I couldn't at the URL in the announcement).
-
-You don't really need the patch however, it's just a shell script that
-in effect does chmod -s on everything in $ORACLE_HOME/bin except
-'oracle' and 'dbsnmp' (needed only for OEM or SNMP).
-
-Also, although the patch didn't address the issue, make sure _nothing_
-below ORACLE_HOME is owned by root. There are some installations that
-make certain files setuid to root (files that are trivial to compromise).
-
-Mark
-
-
-------------------------------------------------------------------------------
-
-From: Dan Sugalski <sugalskd@osshe.edu>
-Date: Mon, 10 May 1999 09:13:28 -0700
-
-The patch actually removes the setuid bit on a number of oracle
-executables. The 'unset' list is:
-
-lsnrctl oemevent onrsd osslogin tnslsnr tnsping trcasst trcroute cmctl
-cmadmin cmgw names namesctl otrccref otrcfmt otrcrep otrccol oracleO
-
-While the 'must set' list is:
-
-oracle dbsnmp
-
-The shell script to fix the bits properly was posted to the oracle list
-running at telelists.com. Check the archives there for it if you want.
-(www.telelists.com) I think it's also gone out to one of the BUGTRAQ
-lists, and some of the CERTs might have it too.
-
- Dan
-
-------------------------------------------------------------------------------
-
-Date: Wed, 12 May 1999 11:49:45 -0700
-From: Mark Dedlow <dedlow@voro.lbl.gov>
-
-> The patch actually removes the setuid bit on a number of oracle
-> executables. The 'unset' list is:
->
-> lsnrctl oemevent onrsd osslogin tnslsnr tnsping trcasst trcroute cmctl
-> cmadmin cmgw names namesctl otrccref otrcfmt otrcrep otrccol oracleO
-
-Actually, there's a little more than that. For each item in that list,
-it also looks for a version of the file with a 0 or O appended to it
-(these are backups the link makefiles create), so the above list isn't
-exactly complete.
-
-The important issues are simply:
-
- o *ONLY* $ORACLE_HOME/bin/oracle requires setuid bit set for
- the Oracle RDBMS and tools to function.
-
- o *IF* you run dbsnmp, it must be setuid. (If you don't know what dbsnmp
- is, you're probably not running it -- it's a remote monitoring/control
- daemon)
-
-Armed with that knowledge, you can use any technique you like to achieve
-the desired results. For example, this achieves it:
-
-find $ORACLE_HOME/bin -perm -2000 ! -name oracle ! -name dbsnmp | xargs chmod -s
-
-Mark
-
-------------------------------------------------------------------------------
-
-One further note I'll pass on anonymously and without comment:
-
-> please include something like: "After removing the setuid bits, slap
-> your system administrator for running root.sh as root without actually
-> reading it first."
-> :)
-
-------------------------------------------------------------------------------
View
236 README.win32.txt
@@ -1,236 +0,0 @@
-In general, on Windows, it's best to just use ActiveState Perl and the
-PPM package manager to install a pre-built version of DBD::Oracle however only version 1.17 is available there.
-
-If you built Perl with gcc, read README.wingcc.txt as well as this file.
-
-
-Oracle Instant Client 11.1.0.6.0 Notes
-
-So far I have managed to get it to Makefile and compile test and install and work. However it seems one needs to set "NLS_LANG" to a valid value
-in the environment variables.
-
-As well IC 11 seems to have trouble finding the .ORA files. A quick fix for this is to add "TNS_ADMIN"
-to the environment variables and point it to where your .ORA files are.
-
-
---- other information, some of which is out of date ---
-
-DBD-Oracle for Windows and Oracle Instantclient and 10XE (Express Edition)
-By: John Scoles Scoles@ptyhian.com
-The Pythian Group
-
-The preferred method of getting DBD::Oracle is to use a pre-built version from the ActiveState
-repository, which can be installed with PPM.
-
-Compiling and installing DBD::Oracle 1.18 or later on a windows 2000 professional or XP OS for use
-with Oracle instantClient ver 10.2.0.1 & 10.1.0.5 or Oracle XE requires only a few downloads and
-a minimal number of environment setting. The procedures below were tested on a clean
-Windows platform having no Oracle or other development environment installed.
-
-1) The first part of the process is to download and install the latest version of
- Active Perl from http://www.activeperl.com/.
-
-2) Use the PPM application to get the latest version of DBI
-
-3) Download the latest DBD::Oracle from http://svn.perl.org/modules/dbd-oracle/trunk/
-
-4) Download and unzip the Oracle Instant Client (10.2.0.1 or 10.1.0.5) 32 bit from
- http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html
- You will need all three of these products
- i. Instant Client Package - Basic
- ii. Instant Client Package - SQL*Plus:
- iii. Instant Client Package - SDK:
- or
-
- install oracle 10XE http://www.oracle.com/technology/products/database/xe/index.html
-
-5) You will now need the Microsoft Visual C++ toolkit 2003. Unfortunately this product is no longer available from Microsoft.
- The file name was VCToolkitSetup.exe and is available at this mirror site http://www.filewatcher.com/m/VCToolkitSetup.exe.32952488.0.0.html at the time of writing.
- Microsoft's replacement for this tool kit is Visual C++ 2005 Express Edition and all attempts to compile DBD::Oracle with this product fail. It has been successfully compiled
- using a complete edition of Microsoft Visual Studio 2005.
- Download and then install this product.
-
-6) You will also need the Windows SDK. Which can be found at
- http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
- You have the choice to of either to download the entire SDK and install or run an online install from the page.
- Both have been tested and proven to work.
-
-7) Next download and install the Microsoft .net framework 1.1 skd from
- http://www.microsoft.com/downloads/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d&displaylang=en
-
-8) You will also need a copy of nmake.exe which you can download here http://download.microsoft.com/download/vc15/patch/1.52/w95/en-us/nmake15.exe
-
-9) Enough Downloading and installing go have a coffee.
-
-10) You should at this time attempt to connect to an Oracle database with the version SQL*Plus that
- you installed in step 4. If you are unable to connect at this stage then any problems you encounter
- later may have nothing to do with DBD::Oracle
-
-11) On the path where you installed Visual C++ find and edit the vcvars32.bat file as follows. You may have to modify
- these path values depending where you installed the products on you computer,
-
- i. Add the local path to the windows platform SDK include directory to the Set INCLUDE
- Command Line to include the needed files from the Windows SDK.
-
- e.g. "C:\Program Files\Microsoft Platform SDK\Include;"
-
- ii. Add the local path to the .net Vc7 lib directory to the Set LIB command
- to include the needed library file from the .Net SKD
-
- e.g. C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib;
-
- iii. Add the local path to the windows platform SDK Lib directory to the Set Lib command
- to include the needed library files from the Windows SDK
-
- e.g. C:\Program Files\Microsoft Platform SDK\Lib;
-
-12) Open a Windows Visual C++ command window from the start menu.
-
-13) Add the path to the instant client to the Path command. If you are compiling aginst a 10XE db/client then you can skip steps
- 12 to 14.
- e.g. PATH = C:/Oracle/instantclient;%PATH%
-
-14) Using the "Set" command add "ORACLE_HOME=path to Instant client" to the environment variables.
- e.g. Set ORACLE_HOME=C:\Oracle\instantclient
-
-15) Using the "Set" command add "NLS_LANG=.WE8ISO8859P15" to the environment variables. The globalization variable is required,
- with this or another compatible value, by Oracle instantclient in order for it to compile correctly.
- e.g. Set NLS_LANG=.WE8ISO8859P15
-
-16) Using the "Set" command add "ORACLE_USERID=test/test@test" substituting test with the username/password@database
- you wish to run the make test files against.
- Note: it is not necessary to do this step for the compile and install to work.
- However: The self-test programs included with Oracle-DBD will mostly fail.
-
-17) Move to the DBD-Oracle directory in the Visual C++ window DOS prompt and enter the following.
-
- c:\oracle-dbd\>perl Makefile.PL
-
- The Makefile should then run and compile Oracle-dbd without reporting any errors.
-
-18) From this DOS prompt enter the following command
-
- c:\oracle-dbd\>nmake
-
- The Visual C++ make executable will then build you DBD-execuable. There should be no errors at this point.
-
-19) You can test the compile by either entering
-
- c:\oracle-dbd\>nmake test
-
- As long as you have given a valid user name, password and database name in step 15 you will see some results. If it appears to
- run but you do not get a connection check the following.
-
- i. User name password and DB Name
- ii. Ensure the a valid TNSNAMES.ORA file is in the Instantclient directory
- iii. Attempt to log into the version of SQLPLUS that comes with Instantclient.
- If you manage to log on use the username password and TNS name with
- the Set ORACLE_USERID = and rerun the tests.
- iv If you are compiling against 10XE and have skiped steps 12 to 14 try again bu this time carry out these steps
-
-20) You can now install DBD-Oracle into you system by entering the following command from the Visual C++ window dos prompt;
-
- c:\oracle-dbd\>nmake install
-
-21) You should now be able to run DBD-Oracle on you system
-
-09/30 2006 from asu <asng@onlinehome.de>
-
-DBD::Oracle 1.18a
-
-Linux, Debian unstable (
-DBI: 1.52
-perl v5.8.8 built for i486-linux-gnu-thread-multi
-)
-
-Oracle Instant client (10.1.0.5)
-
-The problem is in Makefile.PL. In line 130 the function find_oracle_home
-is used to guess a value form $ORACLE_HOME if it is not set explicitely.
-This value is used in line 138 to setup the environment (regardless
-which client is used).
-
-in line 1443 (sub get_client_version) sqlplus is used to get the
-version string, but for the oracle instant client you must not set
-$ORACLE_HOME (it will generate an error "SP2-0642: SQL*Plus internal
-error state 2165, context 4294967295:0:0")
-
-A solution that worked for me was to set
-local $ENV{ORACLE_HOME} = '';
-in line 1463 immediately before sqlplus is called (but I cannot tell if
-this fails for full client installations)
-
-
-11/30/05 -- John Scoles <scoles@pythian.com>
-I have confirmed that this Makefile.pl will work for both Oracle InstantClient
-10.2.0.1 & 10.1.0.4 using same process the Andy Hassall uses. Starting with a clean OD
-One needs only to get the latest version of Active Perl 5.8.7 use PPM to get DBI and then
-install Microsoft Visual C++ toolkit, Windows SDK, and the Microsoft .net
-framework 1.1. and modify the vcvars32.bat in C++ dir as follows
-
- 1) Add the local path to the windows platform SDK include directory to the
- Set INCLUDE Command Line to include the needed files from the Windows SDK.
- e.g. "C:\Program Files\Microsoft Platform SDK\Include;"
- 2) Add the local path to the .net Vc7 lib directory to the Set LIB
- command to include the needed library files from the .Net SKD
- e.g. C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib;
- 3) Add the local path to the windows platform SDK Lib directory to the Set Lib
- command to include the needed library files from the Windows SDK
- e.g. C:\Program Files\Microsoft Platform SDK\Lib;
-
-If one happens to have visual studio installed you may not have to download additional MS products.
-
-12/01/05 --- John Scoles <scoles@pythian.com>
-Oracle 10XE
-No big problem here as 10XE seems to use the instantclient as well. Just ensure your
- NLS_LANG and ORACLE_HOME are set to the same directory that 10XE uses
-
-
-10/07/05 --John Scoles
-Andy Hassall <andy@andyh.co.uk> Kindly added some changes to the Makefile.PL
-so it will work for the Instant Client 10g on Windows OSs. Below is how he set
-up his environment and the steps he preformed to get it to compile.
-
- Setting environment for using Microsoft Visual Studio .NET 2003 tools.
- (If you have another version of Visual Studio or Visual C++ installed and wish
- to use its tools from the command line, run vcvars32.bat for that version.)
-
- C:\Documents and Settings\andyh>d:
-
- D:\>cd cygwin\home\andyh\src\pythian
-
- D:\cygwin\home\andyh\src\pythian>set ORACLE_HOME=d:\lib\instantclient_10_2
-
- D:\cygwin\home\andyh\src\pythian>set NLS_LANG=.WE8ISO8859P15
-
- D:\cygwin\home\andyh\src\pythian>set PATH=d:\lib\instantclient_10_2;D:\Program F
- iles\Microsoft Visual Studio .NET 2003\Common7\IDE;D:\Program Files\Microsoft Vi
- sual Studio .NET 2003\VC7\BIN;D:\Program Files\Microsoft Visual Studio .NET 2003
- \Common7\Tools;D:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\
- bin\prerelease;D:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\
- bin;D:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin;C:\WINNT\Mic
- rosoft.NET\Framework\v1.1.4322;d:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT\
- System32\Wbem;D:\Program Files\Microsoft SDK\Bin;D:\Program Files\Microsoft SDK\
- Bin\WinNT
-
- D:\cygwin\home\andyh\src\pythian>set ORACLE_USERID=test/test@test102
-
- D:\cygwin\home\andyh\src\pythian>perl Makefile.PL
-
-
-
-4/27/04 -- Jeff Urlwin
-
-Do not untar this distribution in a directory with spaces. This will not work.
-
-i.e. C:\Program Files\ORacle\DBD Oracle Distribution is bad while
-c:\dev\dbd-oracle-1.15 is good ;)
-
-9/14/02 -- Michael Chase
-
-Makefile.PL uses Win32::TieRegistry or Win32::Registry to find the
-current Oracle Home directory if the ORACLE_HOME environment variable
-is not set. If neither module is installed, you must set ORACLE_HOME
-before running Makefile.PL. Since the registry location of the current
-Oracle Home is in different locations in different Oracle versions,
-it is usually safer to set ORACLE_HOME before running Makefile.PL.
View
377 lib/DBD/Oracle/Troubleshooting.pm
@@ -1,377 +0,0 @@
-package DBD::Oracle::Troubleshooting;
-#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle
-
-=pod
-
-=head1 CONNECTING TO ORACLE
-
-If you are reading this it is assumed that you have successfully
-installed DBD::Oracle and you are having some problems connecting to
-Oracle.
-
-First off you will have to tell DBD::Oracle where the binaries reside
-for the Oracle client it was compiled against. This is the case when
-you encounter a
-
- DBI connect('','system',...) failed: ERROR OCIEnvNlsCreate.
-
-error in Linux or in Windows when you get
-
- OCI.DLL not found
-
-The solution to this problem in the case of Linux is to ensure your
-'ORACLE_HOME' (or LD_LIBRARY_PATH for InstantClient) environment
-variable points to the correct directory.
-
- export ORACLE_HOME=/app/oracle/product/xx.x.x
-
-For Windows the solution is to add this value to you PATH
-
- PATH=c:\app\oracle\product\xx.x.x;%PATH%
-
-
-If you get past this stage and get a
-
- ORA-12154: TNS:could not resolve the connect identifier specified
-
-error then the most likely cause is DBD::ORACLE cannot find your .ORA
-(F<TNSNAMES.ORA>, F<LISTENER.ORA>, F<SQLNET.ORA>) files. This can be
-solved by setting the TNS_ADMIN environment variable to the directory
-where these files can be found.
-
-If you get to this stage and you have either one of the following
-errors;
-
- ORA-12560: TNS:protocol adapter error
- ORA-12162: TNS:net service name is incorrectly specified
-
-usually means that DBD::Oracle can find the listener but the it cannot connect to the DB because the listener cannot find the DB you asked for.
-
-=head2 Oracle utilities
-
-If you are still having problems connecting then the Oracle adapters
-utility may offer some help. Run these two commands:
-
- $ORACLE_HOME/bin/adapters
- $ORACLE_HOME/bin/adapters $ORACLE_HOME/bin/sqlplus
-
-and check the output. The "Protocol Adapters" should include at least "IPC Protocol Adapter" and "TCP/IP
-Protocol Adapter".
-
-If it generates any errors which look relevant then please talk to your
-Oracle technical support (and not the dbi-users mailing list).
-
-=head2 Connecting using a bequeather
-
-If you are using a bequeather to connect to a server
-on the same host as the client, you might have
-to add
-
- bequeath_detach = yes
-
-to your sqlnet.ora file or you won't be able to safely use fork/system
-functions in Perl.
-
-See the discussion at
-L<http://www.nntp.perl.org/group/perl.dbi.dev/2012/02/msg6837.html>
-and L<http://www.nntp.perl.org/group/perl.dbi.users/2009/06/msg34023.html>
-for more gory details.
-
-
-=head1 USING THE LONG TYPES
-
-Some examples related to the use of LONG types are available in
-the C<examples/> directory of the distribution.
-
-=head1 LINUX
-
-=head2 Installing with Instantclient .rpm files.
-
-Nothing special with this you just have to set up you permissions as follows;
-
-1) Have permission for RWE on '/usr/lib/oracle/10.2.0.3/client/' or the other directory where you RPMed to
-
-2) Set export ORACLE_HOME=/usr/lib/oracle/10.2.0.3/client
-
-3) Set export LD_LIBRARY_PATH=$ORACLE_HOME/lib
-
-4) If you plan to use tnsnames to connect to remote servers and your tnsnames.ora file is not in $ORACLE_HOME/network/admin, you will need to Export TNS_ADMIN=dir to point DBD::Oracle to where your tnsnames.ora file is
-
-=head2 undefined symbol: __cmpdi2 comes up when Oracle isn't properly linked to the libgcc.a library.
-
-In version 8, this was correctd by changing the SYSLIBS entry in
-$ORACLE_HOME/bin/genclntsh to include
-"-L/usr/lib/gcc-lib/i386-redhat-linux/3.2 -lgcc".
-
-I had tried this with no success as when this program was then run, the
-error "unable to find libgcc" was generated. Of course, this was the
-library I was trying to describe!
-
-It turns out that now it is necessary to edit the same file and append
-"`gcc -print-libgcc-file-name`" (including the backquotes!). If you do
-this and then run "genclntsh", the libclntsh is properly generated and
-the linkage with DBD::Oracle proceeds properly.
-
-
-=head2 cc1: invalid option `tune=pentium4'" error
-
-If you get the above it seems that eiter your Perl or OS where compiled with a different version of GCC or the GCC that is on your system is very old.
-
-No real problem with the above however you will have to
-
-1) run Perl Makefile.PL
-
-2) edit the Makefile and remove the offending '-mtune=pentium4' text
-
-3) save and exit
-
-4) do the make install and it should work fine for you
-
-=head2 Oracle 9i Lite
-
-The advice is to use the regular Oracle9i not the lite version.
-
-Another great source of help was: http://www.puschitz.com/InstallingOracle9i.html
-
-just getting 9i and 9i lite installed. I use fvwm2(nvidia X driver) as
-a window manager which does not work with the 9i install program, works
-fine with the default Gnomish(nv X driver), it could have been the X
-driver too.
-
-With Redhat9 it is REAL important to set LD_ASSUME_KERNEL to 2.4.1.
-
-I didn't try this but it may be possible to install what is needed by
-only downloading the first disk saving some 1.3GB of download fun.
-
-I installed a custom install from the client group. The packages I
-installed are the Programmers section and sqlplus. I noticed that the
-Pro*C when on as a result of the checking the Programmers section I
-assume.
-
-Once Oracle was installed properly the DBD::Oracle install went as
-smooth as just about every other CPAN module.
-
-=head2 Oracle 10g Instantclient
-
-The Makefile.PL will now work for Oracle 10g Instantclient. To have both the Compile and
-the test.pl to work you must first have the LD_LIBRARY_PATH correctly set to your
-"instantclient" directory. (http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html)
-
-The present version of the make creates a link on your "instantclient" directory as follows
-"ln -s libclntsh.so.10.1 libclntsh.so". It is needed for both the makefile creation and the compile
-but is not need for the test.pl. It should be removed after the compile.
-
-If the Makefile.PL or make fails try creating this link directly in your "instantclient" directory.
-
-=head2 Oracle Database 10g Express Edition 10.2
-
-To get 10Xe to compile correctly I had to add $ORACLE_HOME/lib to the LD_LIBRARY_PATH
-as you would for an install against 10g Standard Edition, Standard Edition One, or
-Enterprise Edition
-
-=head2 UTF8 bug in Oracle 9.2.0.5.0 and 9.2.0.7.0
-
-DBD::Oracle seems to hit some sort of bug with the above two versions of DB.
-The bug seems to hit when you when the Oracle database charset: US7ASCII and the Oracle nchar charset: AL16UTF16 and it has also
-been reported when the Oracle database charset: WE8ISO8850P1 Oracle nchar charset: AL32UTF16.
-
-So far there is no patch for this but here are some work arounds
-
- use DBD::Oracle qw( SQLCS_IMPLICIT SQLCS_NCHAR );
- ...
- $sth->bind_param(1, $value, { ora_csform => SQLCS_NCHAR });
-
- or this way
-
- $dbh->{ora_ph_csform} = SQLCS_NCHAR; # default for all future placeholders
-
- or this way
-
- utf8::downgrade($parameter, 1);
-
-
-=head1 CYGWIN
-
-Makefile.PL should find and make use of OCI include
-files, but you have to build an import library for
-OCI.DLL and put it somewhere in library search path.
-one of the possible ways to do this is issuing command
-
- dlltool --input-def oci.def --output-lib liboci.a
-
-in the directory where you unpacked DBD::Oracle distribution
-archive. this will create import library for Oracle 8.0.4.
-
-Note: make clean removes '*.a' files, so put a copy in a safe place.
-
-=head2 Compiling DBD::Oracle using the Oracle Instant Client, Cygwin Perl and gcc
-
-=over
-
-=item 1
-
-Download these two packages from Oracle's Instant Client for
-Windows site
-(http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/winsoft.html):
-
-Instant Client Package - Basic: All files required to run OCI,
-OCCI, and JDBC-OCI applications
-
-Instant Client Package - SDK: Additional header files and an
-example makefile for developing Oracle applications with Instant Client
-
-(I usually just use the latest version of the client)
-
-=item 2
-
-Unpack both into C:\oracle\instantclient_11_1
-
-=item 3
-
-Download and unpack DBD::Oracle from CPAN to some place with no
-spaces in the path (I used /tmp/DBD-Oracle) and cd to it.
-
-=item 4
-
-Set up some environment variables (it didn't work until I got the
-DSN right):
-
- ORACLE_DSN=DBI:Oracle:host=oraclehost;sid=oracledb1
- ORACLE_USERID=username/password
-
-=item 5
-
- perl Makefile.PL
- make
- make test
- make install
-
-=back
-
-Note, the TNS Names stuff doesn't always seem to work with the instant
-client so Perl scripts need to explicitly use host/sid in the DSN, like
-this:
-
- my $dbh = DBI->connect('dbi:Oracle:host=oraclehost;sid=oracledb1',
- 'username', 'password');
-
-=head2 SUN
-
-If you get this on a Solaris 9 and 10 box
-
- "Outofmemory!
- Callback called exit.
- END failed--call queue aborted."
-
-The solution may be as simple as not having you "ORACLE_HOME" Defined in the
-environment.
-
-It seems that having it defined will prevent the error.
-
-=head2 VMS
-
-This is related to Oracle RDBMS 9.2 and later, since Oracle
-made fundamental changes to oracle installation requirements
-and factual installation with this release.
-
-Oracle's goal was to make VMS installation be more like on
-*nix and Windows, with an all new Oracle Home structure too,
-requiring an ODS-5 disk to install Oracle Home on instead of
-the good old ODS-2.
-
-Another major change is the introduction of an Oracle generated
-logical name table for oracle logical names like ORA_ROOT and all
-its derivatives like ORA_PROGINT etc. And that this logical name
-table is inserted in LNM$FILE_DEV in LNM$PROCESS_DIRECTORY.
-
- (LNM$PROCESS_DIRECTORY)
-
- "LNM$FILE_DEV" = "SERVER_810111112"
- = "LNM$PROCESS"
- = "LNM$JOB"
- = "LNM$GROUP"
- = "LNM$SYSTEM"
- = "DECW$LOGICAL_NAMES"
-
-This ensures that any process that needs to have access to
-oracle gets the environment by just adding one logical name table
-to a central process specific mechanism.
-
-But as it is inserted at the very top of LNM$FILE_DEV it also
-represents a source of misfortune - especially if a user with
-enough privilege to update the oracle table does so (presumably
-unintentionally), as an examble by changing NLS_LANG.
-
-PERL has the abillity to define, redefine and undefine (deassign)
-logical names, but if not told otherwise by the user does it
-in the first table in above list, and not as one would normally
-expect in the process table.
-
-Installing DBI and DBD::Oracle has influence upon this since in
-both cases a few environment variables are read or set in the
-test phase.
-For DBI it is the logical SYS$SCRATCH, which is a JOB logical.
-For DBD-Oracle it is when testing a new feature in the Oracle
-RDBMS: UTF8 and UTF16 character set functionality, and in order
-to do this it sets and unsets the related environment variables
-NLS_NCHAR and NLS_LANG.
-
-If one is not careful this changes the values set in the oracle
-table - and in the worst case stays active until the next major
-system reset. It can also be a very hard error to track down
-since it happens in a place where one normally never looks.
-
-Furthermore, it is very possibly that some or all of the UTF tests
-fails, since if one have a variable like NLS_LANG in his process
-table, then even though 'mms test' sets it in the wrong table
-it is not invoked as it is overruled by the process logical...
-
-The way to ensure that no logicals are set in the oracle table and
-that the UTF tests get the best environment to test in, and that
-DBI correctly translates the SYS$SCRATCH logical, use the
-logical
-
- PERL_ENV_TABLES
-
-to ensure that PERL's behavior is to leave the oracle table alone and
-use the process table instead:
-
- $ DEFINE PERL_ENV_TABLES LNM$PROCESS, LNM$JOB
-
-This tells PERL to use the LNM$PROCESS table as the default place to
-set and unset variables so that only the perl users environment
-is affected when installing DBD::Oracle, and ensures that the
-LNM$JOB table is read when SYS$SCRATCH is to be translated.
-
-PERL_ENV_TABLES is well documented in the PERLVMS man page.
-
-Oracle8 releases are not affected, as they don't have the
-oracle table implementation, and no UTF support.
-
-Oracle 9.0 is uncertain, since testing has not been possible yet,
-but the remedy will not hurt :)
-
-=head1 Miscellaneous
-
-=head2 Crash with an open connection and Module::Runtime in mod_perl2
-
-See RT 72989 (https://rt.cpan.org/Ticket/Display.html?id=72989)
-
-Apache2 MPM Prefork with mod_perl2 will crash if Module::Runtime is
-loaded, and an Oracle connection is opened through PerlRequire (before
-forking).
-
-It looks like this was fixed in 0.012 of Module::Runtime.
-
-=head2 bin_param_inout swapping return values
-
-See RT 71819 (https://rt.cpan.org/Ticket/Display.html?id=71819)
-
-It seems that in some older versions of Oracle Instant Client
-(certainly 10.2.0.4.0) when output parameters are bound with lengths
-greater than 3584 the output parameters can be returned in the wrong
-placeholders.
-
-It is reported fixed in Instant Client 11.2.0.2.0.
-
-=cut
View
125 lib/DBD/Oracle/Troubleshooting.pod
@@ -0,0 +1,125 @@
+#PODNAME: DBD::Oracle::Troubleshooting
+#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle
+
+=head1 CONNECTING TO ORACLE
+
+If you are reading this it is assumed that you have successfully
+installed DBD::Oracle and you are having some problems connecting to
+Oracle.
+
+First off you will have to tell DBD::Oracle where the binaries reside
+for the Oracle client it was compiled against. This is the case when
+you encounter a
+
+ DBI connect('','system',...) failed: ERROR OCIEnvNlsCreate.
+
+error in Linux or in Windows when you get
+
+ OCI.DLL not found
+
+The solution to this problem in the case of Linux is to ensure your
+'ORACLE_HOME' (or LD_LIBRARY_PATH for InstantClient) environment
+variable points to the correct directory.
+
+ export ORACLE_HOME=/app/oracle/product/xx.x.x
+
+For Windows the solution is to add this value to you PATH
+
+ PATH=c:\app\oracle\product\xx.x.x;%PATH%
+
+
+If you get past this stage and get a
+
+ ORA-12154: TNS:could not resolve the connect identifier specified
+
+error then the most likely cause is DBD::ORACLE cannot find your .ORA
+(F<TNSNAMES.ORA>, F<LISTENER.ORA>, F<SQLNET.ORA>) files. This can be
+solved by setting the TNS_ADMIN environment variable to the directory
+where these files can be found.
+
+If you get to this stage and you have either one of the following
+errors;
+
+ ORA-12560: TNS:protocol adapter error
+ ORA-12162: TNS:net service name is incorrectly specified
+
+usually means that DBD::Oracle can find the listener but the it cannot connect to the DB because the listener cannot find the DB you asked for.
+
+=head2 Oracle utilities
+
+If you are still having problems connecting then the Oracle adapters
+utility may offer some help. Run these two commands:
+
+ $ORACLE_HOME/bin/adapters
+ $ORACLE_HOME/bin/adapters $ORACLE_HOME/bin/sqlplus
+
+and check the output. The "Protocol Adapters" should include at least "IPC Protocol Adapter" and "TCP/IP
+Protocol Adapter".
+
+If it generates any errors which look relevant then please talk to your
+Oracle technical support (and not the dbi-users mailing list).
+
+=head2 Connecting using a bequeather
+
+If you are using a bequeather to connect to a server
+on the same host as the client, you might have
+to add
+
+ bequeath_detach = yes
+
+to your sqlnet.ora file or you won't be able to safely use fork/system
+functions in Perl.
+
+See the discussion at
+L<http://www.nntp.perl.org/group/perl.dbi.dev/2012/02/msg6837.html>
+and L<http://www.nntp.perl.org/group/perl.dbi.users/2009/06/msg34023.html>
+for more gory details.
+
+
+=head1 USING THE LONG TYPES
+
+Some examples related to the use of LONG types are available in
+the C<examples/> directory of the distribution.
+
+=head1 Can't find I<libclntsh.so>
+
+I<libclntsh.so> is the shared
+library composed of all the other Oracle libs you used to have to
+statically link.
+libclntsh.so should be in I<$ORACLE_HOME/lib>. If it's missing, try
+running I<$ORACLE_HOME/lib/genclntsh.sh> and it should create it.
+
+Never copy I<libclntsh.so> to a different machine or Oracle version.
+If DBD::Oracle was built on a machine with a different path to I<libclntsh.so>
+then you'll need to set set an environment variable, typically
+I<LD_LIBRARY_PATH>, to include the directory containing I<libclntsh.so>.
+
+I<LD_LIBRARY_PATH> is typically ignored if the script is running set-uid
+(which is common in some httpd/CGI configurations). In this case
+either rebuild with I<LD_RUN_PATH> set to include the path to I<libclntsh>
+or create a symbolic link so that I<libclntsh> is available via the same
+path as it was when the module was built. (On Solaris the command
+"ldd -s Oracle.so" can be used to see how the linker is searching for it.)
+
+=head1 Miscellaneous
+
+=head2 Crash with an open connection and Module::Runtime in mod_perl2
+
+See RT 72989 (https://rt.cpan.org/Ticket/Display.html?id=72989)
+
+Apache2 MPM Prefork with mod_perl2 will crash if Module::Runtime is
+loaded, and an Oracle connection is opened through PerlRequire (before
+forking).
+
+It looks like this was fixed in 0.012 of Module::Runtime.
+
+=head2 bin_param_inout swapping return values
+
+See RT 71819 (https://rt.cpan.org/Ticket/Display.html?id=71819)
+
+It seems that in some older versions of Oracle Instant Client
+(certainly 10.2.0.4.0) when output parameters are bound with lengths
+greater than 3584 the output parameters can be returned in the wrong
+placeholders.
+
+It is reported fixed in Instant Client 11.2.0.2.0.
View
250 lib/DBD/Oracle/Troubleshooting/Aix.pod
@@ -0,0 +1,250 @@
+#PODNAME: DBD::Oracle::Troubleshooting::Aix
+#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on AIX
+
+=head1 Using Visual Age 7 C Compiler
+
+Oracle 9i is only certified as a 64-bit application on AIX 5L (5.1,5.2,5.3) with 32-bit support;
+in other words, there is no 9i "32-bit" Oracle client
+
+Oracle 10g is certified as both a 64-bit application and a 32-bit Oracle client
+
+This information only pertains to deploying:
+
+ the DBI (version 1.48)
+ and DBD-Oracle (version 1.16):
+ on AIX 5.3
+ using Oracle 9i (9.2.0.1/9.2.0.5)
+ using the existing Perl 5.8.2 (no custom-built Perl) which is 32-bit
+ using Visual Age 7.0 C/C++ compiler
+
+Install the DBI (required for the DBD-Oracle install - no issues here)
+Untar the DBD-Oracle bundle
+Run Makefile.PL
+
+ $ perl Makefile.PL
+
+Edit Makefile with following commands:
+
+ 1,$s?/lib/ ?/lib32/ ?g
+ 1,$s?-q64??g
+ 1,$s?/lib/sysliblist?/lib32/sysliblist?g
+
+Now perform normal commands to perform the testing/making:
+
+ $ make
+ $ make test
+ $ make install
+
+I've tested the basics of the DBD-Oracle and it seems fully functional.
+
+Stephen de Vries
+
+
+=head1 Using gcc C Compiler
+
+ DBD::Oracle with gcc and Oracle Instant Client on AIX
+ --------------------------------------------------------------------------------------
+ Nathan Vonnahme Dec 15 2005, 4:28 pm Newsgroups: perl.dbi.users
+ See: http://groups.google.com/group/perl.dbi.users/msg/0bd9097f80f2c8a9
+ [ with updates 1/31/2006 - DBD::Oracle 1.17 doesn't need makefile hacking
+ to work with instantclient on AIX ]
+
+
+ Yes! It eluded me last year but I finally got DBD::Oracle working on an
+ AIX machine using gcc. Here's the short version:
+
+ First I had to recompile perl with gcc, using
+ sh Configure -de -Dcc=gcc
+ This apparently built a 32 bit perl, someday I will try getting it to go
+ 64 bit.
+
+ I was then able to install and build DBI 1.50 with the CPAN shell.
+
+ I downloaded the base and sdk packages of the Oracle Instant Client for
+ AIX -- first I tried the 64 bit but that didn't work with my 32 bit perl
+ -- the 32 bit version (still at 10.1.0.3) did the trick. I unzipped
+ them and moved the dir to /usr/local/oracle/instantclient10_1 and made a
+ symlink without the version at /usr/local/oracle/instantclient , then
+ set:
+
+ export ORACLE_HOME=/usr/local/oracle/instantclient
+ export LIBPATH=$ORACLE_HOME
+
+
+
+ Oracle wasn't providing the sqlplus package for 32 bit AIX so I
+ explicitly told Makefile.PL the version:
+
+ perl Makefile.PL -V 10.1
+
+ make
+
+ My test databases were on other machines so I set these environment variables
+ to get the tests to run:
+
+ export ORACLE_DSN=DBI:Oracle://host/dbinstance
+ export ORACLE_USERID="user/password"
+
+ make test
+ make install
+
+
+ NOTE: I have an older full version of Oracle on this machine, and the
+ ORACLE_HOME environment variable is normally set to point to that, so
+ my perl scripts that use DBD::Oracle have to make sure to first set
+ $ENV{ORACLE_HOME}='/usr/local/oracle/instantclient';
+
+
+
+
+
+ --------------------------------------------------------------------------------------
+ The following setup worked to build on AIX 5.2:
+ gcc-3.3.2 (32-bit) (configure opts [ --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as])
+ Oracle-9.2.0 ( full install w/32bit support)
+ perl-5.8.3 (built with above gcc/latest stable as of March 2004)
+ Followed the directions from Rafael's email below, only set ORACLE_HOME, (and
+ the appropriate test environmentals).
+ 1) build perl-5.8.3 with gcc
+ 2) install DBI
+ 3) ORACLE_HOME="your oracle home"
+ ORACLE_USERID..
+ ORACLE_SID ..
+ (I ignored ORACCENV, didn't use it.)
+ 4) install DBD::Oracle, after perl Makefile.PL, edit the created Makefile,
+ changing references to Oracle's ../lib to ../lib32. and change crt0_64.o to
+ crt0_r.o. Remove the -q32 and/or -q64 options from the list of libraries to
+ link with.
+ 5) make should be clean, make test should pass.
+ This setup worked with 8.1.7 w/32 bit support, and with 9.2.0 w/ 32-bit support.
+ --Adrian Terranova
+
+
+=head1 Using xlc_r C Compiler
+
+ From: Rafael Caceres
+ Date: 22 Jul 2003 10:05:20 -0500
+
+ The following sequence worked for me on AIX 5.1:
+
+ -use Perl 5.8.0 (the latest stable from CPAN)
+
+ -use the xlc_r version of IBM's compiler and build a 32 bit Perl
+ (which xlc_r will do by default). All tests should be successful.
+
+ -get and install DBI
+
+ -get DBD::Oracle. Edit the Makefile.PL or Makefile for DBD::Oracle,
+ changing references to Oracle's ../lib to ../lib32. and change crt0_64.o
+ to crt0_r.o. Remove the -q32 and/or -q64 options from the list of
+ libraries to link with. Do the make and make test.
+
+ -Set up the environment for making DBD::Oracle:
+ ORACLE_HOME="your oracle home"
+ ORACCENV = "xlc_r"
+ ORACLE_USERID..
+ ORACLE_SID ..
+
+ -Run make, all tests should be successfull -against Oracle 9.x at least.
+
+ You should have no problems with Oracle 8.1.7, but accessing Oracle 7.x
+ or previous is not possible (you'll core dump, or simply hang). The same
+ goes for a Linux build or a Digital build, regarding access of different
+ Oracle versions.
+
+ Rafael Caceres
+
+ > I dont believe I compiled Oracle. During the installation it was linked
+ > but I am not sure it was compiled
+ >
+ > I used a xlc compiler to compile PERL.
+ > Got this message in the Perl Makefile.PL output
+ >
+ > Warning: You will may need to rebuild perl using the xlc_r compiler.
+ > You may also need do: ORACCENV='cc=xlc_r'; export ORACCENV
+ > Also see the README about the -p option
+ >
+ > this probobly means I need to rebuild PERL with xlc_r??
+ >
+ > thanx
+ >
+ > Mike Paladino
+ > Database Administrator
+
+
+ From: Rafael Caceres
+ >
+ > Make sure you use the same compiler to build Oracle and Perl. We have
+ > used xlc_r on Aix 5.1 with no problems. Your Perl build is 32 bit, so
+ > when building DBD::Oracle, you should use the 32bit libraries (change
+ > references to .../oracle/lib to .../oracle/lib32 in your Makefile).
+ > Remove the references to the -q64 or -q32 parameters for ld in Makefile,
+ > as they shouldn't be there.
+ >
+ > Rafael Caceres
+
+
+ From: "cartman ltd"
+ Subject: Tip for DBI and DBD::Oracle on AIX 5.1 and Oracle 9.2
+ Date: Mon, 11 Aug 2003 18:15:38 +0000
+ Message-ID: <BAY1-F58Temqpg2ItZe00032a0f@hotmail.com>
+
+ Here is a tip for compiling DBD::Oracle as a 32 bit application on AIX 5.1
+ 64 bit and Oracle 9.2 64 bit without editting any makefiles. I hope people
+ find this useful:
+
+ First, the versions of products I used:
+ DBI version 1.32
+ DBD::Oracle version 1.14
+ Oracle 9.2.0.2 - default 64 bit application with 32 bit libraries
+ AIX 5.1 ML03 - 64 bit kernel - ships with Perl as a 32 bit application.
+ VisualAge C/C++ 5.0.2
+
+ Basically DBD must be compiled as 32 bit to link with Perl's 32 bit
+ libraries.
+ gunzip -c DBD-Oracle-1.14.tar.gz | tar xvf 
+ cd DBD-Oracle-1.14
+ perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/demo_rdbms32.mk
+ make
+
+ NB: I think there is a bug in the Oracle 9.2.0.3 file
+ $ORACLE_HOME/rdbms/lib/env_rdbms.mk
+ I corrected this (before running the above commands) by replacing the
+ invalid linker option
+ LDFLAGS32=-q32
+ with
+ LDFLAGS32=-b32
+
+ Have fun: KC.
+ --------------------------------------------------------------------------------------
+
+ Date: Wed, 30 Jun 2004 23:34:24 -0500
+ From: "SCHULTZ, DARYLE (SBCSI)"
+
+ Got it to work. Using dbd 1.16
+
+ Perl 5.8.4 built like this, with Visual Age 6.0:
+
+ config_args='-Dcc=xlc_r -Dusenm -Dprefix=/appl/datasync/work/perl5
+ -Dusethreads -Duse64bitall -des'
+ ==============================================
+
+ Used DBI 1.42
+ =============================================
+ Added this to top of Oracle.h:
+ #define A_OSF
+