Front page | perl.dbd.oracle.changes |
Postings from December 2005
[svn:dbd-oracle] r2296 - dbd-oracle/branches/pythian
From:
byterock
Date:
December 5, 2005 06:06
Subject:
[svn:dbd-oracle] r2296 - dbd-oracle/branches/pythian
Message ID:
20051205131816.15663.qmail@x1.develooper.com
Author: byterock
Date: Mon Dec 5 05:18:15 2005
New Revision: 2296
Added:
dbd-oracle/branches/pythian/README.aix.txt
dbd-oracle/branches/pythian/README.clients.txt
dbd-oracle/branches/pythian/README.explain.txt
dbd-oracle/branches/pythian/README.help.txt
dbd-oracle/branches/pythian/README.hpux.txt
dbd-oracle/branches/pythian/README.java.txt
dbd-oracle/branches/pythian/README.linux.txt
dbd-oracle/branches/pythian/README.login.txt
dbd-oracle/branches/pythian/README.longs.txt
dbd-oracle/branches/pythian/README.macosx.txt
dbd-oracle/branches/pythian/README.sec.txt
dbd-oracle/branches/pythian/README.utf8.txt
dbd-oracle/branches/pythian/README.vms.txt
dbd-oracle/branches/pythian/README.win32.txt
dbd-oracle/branches/pythian/README.wingcc.txt
Log:
Updated win32 readme and renamed readme.foo to readme.foo.txt
Added: dbd-oracle/branches/pythian/README.aix.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.aix.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,184 @@
+Compiler: all these examples use xlc_r, except the first which uses Visual Age 7
+and the second which uses GCC.
+
+--------------------------------------------------------------------------------------
+- 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
+
+--------------------------------------------------------------------------------------
+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
+
+--------------------------------------------------------------------------------------
+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.
+
+--------------------------------------------------------------------------------------
Added: dbd-oracle/branches/pythian/README.clients.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.clients.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,274 @@
+This file contains some random notes relating to minimal Oracle
+configurations for building and/or using DBD::Oracle / Oraperl.
+
+-------------------------------------------------------------------------------
+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
+
+-------------------------------------------------------------------------------
Added: dbd-oracle/branches/pythian/README.explain.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.explain.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,193 @@
+explain
+=======
+
+DISCLAIMER & COPYRIGHT
+----------------------
+
+Copyright (c) 1998 Alan Burlison
+
+You may distribute under the terms of either the GNU General Public License
+or the Artistic License, as specified in the Perl README file, with the
+exception that it cannot be placed on a CD-ROM or similar media for commercial
+distribution without the prior approval of the author.
+
+This code is provided with no warranty of any kind, and is used entirely at
+your own risk.
+
+This code was written by the author as a private individual, and is in no way
+endorsed or warrantied by Sun Microsystems.
+
+WHAT IS IT?
+-----------
+explain is a GUI-based tool that enables easier visualisation of Oracle Query
+plans. A query plan is the access path that Oracle will use to satisfy a SQL
+query. The Oracle query optimiser is responsible for deciding on the optimal
+path to use. Needless to say, understanding such plans requires a fairly
+sophisticated knowledge of Oracle architecture and internals.
+
+explain allows a user to interactively edit a SQL statemant and view the
+resulting query plan with the click of a single button. The effects of
+modifying the SQL or of adding hints can be rapidly established.
+
+explain allows the user to grab all the SQL currently cached by Oracle. The SQL
+capture can be filtered and sorted by different criterea, e.g. all SQL matching
+a pattern, order by number of executions etc.
+
+explain is written using Perl, DBI/DBD::Oracle and Tk.
+
+PREREQUISITES
+-------------
+1. Oracle 7 or Oracle 8, with SQL*Net if appropriate
+2. Perl 5.004_04 or later
+3. DBI version 0.93 or later
+4. DBD::Oracle 0.49 or later
+5. Tk 800.005 or later
+6. Tk-Tree 3.00401 or later
+
+Items 2 through 6 can be obtained from any CPAN mirror.
+
+INSTALLATION
+------------
+1. Check you have all the prequisites installed and working.
+2. Check the #! line in the script points to where your Perl interpreter is
+ installed.
+3. Copy the "explain" script to somewhere on your path.
+4. Make sure the "explain" script is executable.
+5. Make sure you have run the script $ORACLE_HOME/rdbms/admin/utlxplan.sql
+ from a SQL*Plus session. This script creates the PLAN_TABLE that is used
+ by Oracle when explaining query plans.
+
+HOW TO USE
+----------
+
+Type "explain" at the shell prompt. A window will appear with a menu bar and
+three frames, labelled "Query Plan", "Query Step Details" and "SQL Editor". At
+the bottom of the window is a single button labelled "Explain". A login dialog
+will also appear, into which you should enter the database username, password
+and database instance name (SID). The parameters you enter are passed to the
+DBI->connect() method, so if you have any problems refer to the DBI and
+DBD::Oracle documentation.
+
+Optionally you may supply up to two command-line arguments. If the first
+argument is of the form username/password@database, explain will use this to
+log in to Oracle, otherwise if it is a filename it will be loaded into the SQL
+editor. If two arguments are supplied, the second one will be assumed to be a
+filename.
+
+Examples:
+ explain scott/tiger@DB query.sql
+ explain / query.sql (assumes OPS$ user authentication)
+ explain query.sql
+
+
+Explain functionality
+---------------------
+
+The menu bar has one pulldown menu, "File", which allows you to login to Oracle,
+Grab the contents of the Oracle SQL cache, Load SLQ from files, Save SQL to
+files and to Exit the program.
+
+The "SQL Editor" frame allows the editing of a SQL statement. This should be
+just a single statement - multiple statements are not allowed. Refer to the
+documentation for the Tk text widget for a description of the editing keys
+available. Text may be loaded and saved by using the "File" pulldown menu.
+
+Once you have entered a SQL statement, the "Explain" button at the bottom of
+the window will generate the query plan for the statement. A tree
+representation of the plan will appear in the "Query Plan" frame. Individual
+"legs" of the plan may be expanded and collapsed by clicking on the "+' and "-"
+boxes on the plan tree. The tree is drawn so that the "innermost" or "first"
+query steps are indented most deeply. The connecting lines show the
+"parent-child" relationships between the query steps. For a comprehensive
+explanation of the meaning of query plans you should refer to the relevant
+Oracle documentation.
+
+Single-clicking on a plan step in the Query Plan pane will display more
+detailed information on that query step in the Query Step Details frame. This
+information includes Oracle's estimates of cost, cardinality and bytes
+returned. The exact information displayed depends on the Oracle version.
+Again, for detailed information on the meaning of these fields, refer to the
+Oracle documentation.
+
+Double-clicking on a plan step that refers to either a table or an index will
+pop up a dialog box showing the definitiaon of the table or index in a format
+similar to that of the SQL*Plus 'desc' command.
+
+Grab functionality
+-----------------
+
+The explain window has an option on the "File" menu labelled "Grab SQL ...".
+Selecting this will popup a new top-level window containing a menu bar and
+three frames, labelled "SQL Cache", "SQL Statement Statistics" and "SQL
+Selection Criterea". At the bottom of the window is a single button labelled
+"Grab".
+
+The menu bar has one pulldown menu, "File", which allows you to Save the
+contents of the SQL Cache frame and Close the Grab window.
+
+The "SQL Cache" frame shows the statements currently in the Oracle SQL cache.
+Text may be saved by using the "File" pulldown menu.
+
+The "SQL Selection Criterea" frame allows you to specify which SQL statements
+you are interested in, and how you want them sorted. The pattern used to select
+statements is a normal perl regexp. Once you have defined the selection
+criterea, clicking the "Grab" button will read all the matching statements from
+the SQL cache and display them in the top frame.
+
+Single-clicking on a statement in the SQL Cache pane will display more
+detailed information on that statement in the Sql Statement Statistics frame,
+including the number of times the statement has been executed and the numbers
+of rows processed by the statement.
+
+Double-clicking on a statement will copy it into the SQL editor in the Explain
+window, so that the query plan for the statement can be examined.
+
+SUPPORT
+-------
+
+Support questions and suggestions can be directed to Alan.Burlison@uk.sun.com
+
+
+CHANGES
+=======
+
+Version 0.51 beta 09/08/98
+---------------------------
+
+Integrated into DBD::Oracle release 0.54.
+
+Version 0.5 beta 02/06/98
+--------------------------
+Changes made to work with Tk800.005.
+Fixed bug with grab due to Oracle's inconsistent storage of the hash_value
+column in v$sqlarea and v$sqltext_with_newlines.
+Disallowed multiple concurrent login/save/open dialogs.
+Fixed double-posting of login dialog on startup.
+Tried to make it less Oracle version dependent.
+
+Version 0.4 beta 27/02/98
+--------------------------
+Grab functionality added, to allow interrogation of Oracle's SQL cache
+Bind variables used wherever possible to prevent unnecessary reparses of the
+SQL generated by explain
+Extra error checking
+Various code cleanups & restructuring
+More extensive commenting of the source
+
+Version 0.3 beta 19/02/98
+--------------------------
+Changed to use new Tk FileSelect instead of older FileDialog.
+Added facility to supply user/pass@database & SQL filename on the command-line.
+Thanks to Eric Zylberstejn <ezylbers@capgemini.fr> for the patch + suggestions.
+Added check on login to Oracle for a PLAN_TABLE in the user's schema.
+
+Version 0.2 beta 05/02/98
+--------------------------
+Changed to work with both Oracle 7 and 8 statistics.
+Pop-up table & index description dialogs added.
+First public version.
+
+Version 0.1 beta 27/01/98
+--------------------------
+Initial version.
+Not publically released.
Added: dbd-oracle/branches/pythian/README.help.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.help.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,424 @@
+===============================================================================
+Platform or Oracle Version specific notes, hints, tips etc:
+
+Note that although some of these refer to specific systems and versions the
+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
+
+set
+ cc='xlc_r'
+in config.sh. Rebuild everything, and make sure xlc_r is used everywhere.
+set environment
+ ORACCENV='cc=xlc_r'; export ORACCENV
+to enforce this in oraxlc
+
+Thanks to Goran Thyni <goran@bildbasen.kiruna.se> for this information.
+
+-------------------------------------------------------------------------------
+AIX - core dump on disconnect (SIGILL signal)
+
+Try setting BEQUEATH_DETACH=YES in SQLNET.ORA and restarting Oracle instance.
+See 'Hang during "repetitive connect/open/close/disconnect" test' below.
+
+-------------------------------------------------------------------------------
+HP-UX: General
+
+Read README.hpux. Then read it again.
+
+HP's bundled C compiler is dumb. Very dumb. You're almost bound to have
+problems if you use it - you'll certainly need to do a 'static link'
+(see elsewhere). It is recommended that you use HP's ANSI C compiler
+(which costs) or fetch and build the free GNU GCC compiler (v2.7.2.2 or later).
+
+Note that using shared libraries on HP-UX 10.10 (and others?) requires
+patch 441647. With thanks to John Liptak <jliptak@coefmd3.uswc.uswest.com>.
+
+-------------------------------------------------------------------------------
+HP-UX: Terry Greenlaw <z50816@mip.lasc.lockheed.com>
+
+I traced a problem with "ld: Invalid loader fixup needed" to the file
+libocic.a. On HP-UX 9 it contains position-dependant code and cannot be
+used to generate dynamic load libraries. The only shared library that
+Oracle ships under HP-UX is liboracle.sl which replaces libxa.a,
+libsql.a, libora.a, libcvg.a, and libnlsrtl.a. The OCI stuff still
+appears to only link statically under HU-UX 9.x [10.x seems okay].
+
+You'll need to build DBD::Oracle statically linked into the perl binary.
+See the static linking notes below.
+
+If you get an error like: Bad magic number for shared library: Oracle.a
+You'll need to build DBD::Oracle statically linked into the perl binary.
+
+HP-UX 10 and Oracle 7.2.x do work together when creating dynamic libraries.
+The problem was older Oracle libraries were built without the +z flag to cc,
+and were therefore position-dependent libraries that can't be linked
+dynamically. Newer Oracle releases don't have this problem and it may be
+possible to even use the newer Oracle libraries under HP-UX 9. Oracle 7.3
+will ONLY work under HP-UX 10, however.
+
+HP-UX 10 and Oracle 7.3.x seem to have problems. You'll probably need
+to build DBD::Oracle statically linked (see below). The problem seems
+to be related to Oracle's own shared library code trying to do a
+dynamic load (from lxfgno() in libnlsrtl3.a or libclntsh.sl). If you
+get core dumps on login try uncommenting the /* #define signed */ line
+in dbdimp.h as a long-shot. Please let me know if this fixes it for you
+(but I doubt it will).
+
+-------------------------------------------------------------------------------
+For platforms which require static linking.
+
+You'll need to build DBD::Oracle statically linked and then link it
+into a perl binary:
+
+ perl Makefile.PL LINKTYPE=static
+ make
+ make perl (makes a perl binary in current directory)
+ make test FULLPERL=./perl (run tests using the new perl binary)
+ make install
+
+You will probably need to have already built and installed a static
+version of the DBI in order that it be automatically included when
+you do the 'make perl' above.
+
+Remember that you must use this new perl binary to access Oracle.
+
+-------------------------------------------------------------------------------
+Error: Can't find loadable object for module DBD::Oracle in @INC ...
+
+You probably built DBD::Oracle for static linking rather than dynamic
+linking. See 'For platforms which require static linking' above for
+more info. If your platform supports dynamic linking then try to work
+out why DBD::Oracle got built for static linking.
+
+-------------------------------------------------------------------------------
+Error: Syntax warnings/errors relating to 'signed'
+
+Remove the /* and */ surrounding the '/* #define signed */' line in dbdimp.h
+
+-------------------------------------------------------------------------------
+ORA-00900: invalid SQL statement "begin ... end"
+
+You probably don't have PL/SQL Oracle properly/fully installed.
+
+-------------------------------------------------------------------------------
+Connection/Login slow. Takes a long time and may coredump
+
+Oracle bug number: 227321 related to changing the environment before
+connecting to oracle. Reported to be fixed in 7.1.6 (or by patch 353611).
+
+To work around this bug, do not set any environment variables in your
+oraperl script before you call ora_login, and when you do call
+ora_login, the first argument must be the empty string. This means
+that you have to be sure that your environment variables ORACLE_SID
+and ORACLE_HOME are set properly before you execute any oraperl
+script. It is probably also possible to pass the SID to ora_login as
+part of the username (for example, ora_login("", "SCOTT/TIGER@PROD",
+"")), although I have not tested this.
+This workaround is based on information from Kevin Stock.
+
+Also check $ORACLE_HOME/otrace/admin. If it contains big *.dat files
+then you may have otrace enabled. Try setting EPC_DISABLED=TRUE
+in the environment of the database and listener before they're started.
+Oracle 7.3.2.2.0 sets this to FALSE by default, which turns on tracing
+of all SQL statements, and will cause very slow connects once that
+trace file gets big. You can also add (ENVS='EPC_DISABLED=TRUE') to
+the SID_DESC part of listener.ora entries. (With thanks to Johan
+Verbrugghen jverbrug@be.oracle.com)
+
+-------------------------------------------------------------------------------
+Connection/Login takes a long time
+
+Try connect('', 'user/passwd@tnsname', ''). See README.login and item above.
+
+-------------------------------------------------------------------------------
+Error: ORA-00604: error occurred at recursive SQL level (DBD: login failed)
+
+This can happen if TWO_TASK is defined but you connect using ORACLE_SID.
+
+-------------------------------------------------------------------------------
+Error: ld: Undefined symbols _environ _dlopen _dlclose ...
+Environment: SunOS 4.1.3, Oracle 7.1.6 Steve Livingston <mouche@hometown.com>
+
+If you get link errors like: ld: Undefined symbols _environ _dlopen _dlclose ...
+and the link command line includes '-L/usr/5lib -lc' then comment out the
+'CLIBS= $(OTHERLIBS) -L/usr/5lib -lc' line in the Makefile.
+
+-------------------------------------------------------------------------------
+Error: fatal: relocation error: symbol not found: main
+Environment: Solaris, GCC
+
+Do not use GNU as or GNU ld on Solaris. Delete or rename them, they are
+just bad news. In the words of John D Groenveld <groenvel@cse.psu.edu>:
+Run, dont walk, to your console and 'mv /opt/gnu/bin/as /opt/gnu/bin/gas;
+mv /opt/gnu/bin/ld /opt/gnu/bin/gld'. You can add -v to the gcc command
+in the Makefile to see what GCC is using.
+
+-------------------------------------------------------------------------------
+Error: relocation error:symbol not found:setitimer
+Environment: SVR4, stephen.zander@mckesson.com
+
+Error: can't load ./blib/arch/auto/DBD/Oracle/Oracle.so for module DBD::Oracle:
+DynamicLinker:/usr/local/bin/perl:relocation error:symbol not found:setitimer
+Fix: Try adding the '-lc' to $ORACLE_HOME/rdbms/lib/sysliblist (just
+make sure it's not on a new line).
+
+-------------------------------------------------------------------------------
+Error: relocation error:symbol not found:mutex_init
+Environment: UnixWare 7.x, earle.nietzel@es.unisys.com
+
+On the UnixWare 7.x platform the compiler flag -Kthread is commonly used
+when compiling for mulithread however in this case you should use -lthread.
+The compiler will complain that you should be using -Kthread and not
+-lthread, you should ignore these messages. Besure to check this compiler
+flag in $ORACLE_HOME/lib/sysliblist also.
+
+-------------------------------------------------------------------------------
+Error: Undefined symbols __cg92_used at link time.
+Environment: Solaris, GCC
+
+Fix: If you're compiling Oracle applications with gcc on Solaris you need to
+link with a file called $ORACLE_HOME/lib/__fstd.o. If you compile with the
+SparcWorks compiler you need to add the command line option on -xcg92
+to resolve these symbol problems cleanly.
+
+Alligator Descartes <descarte@hermetica.com>
+
+-------------------------------------------------------------------------------
+Environment: SunOS 4.1.3, Oracle 7.1.3 John Carlson <carlson@tis.llnl.gov>
+
+Problem: oraperl and DBD::Oracle fail to link. Some messing around with
+the library order makes the link succeed. Now I get a "Bad free()" when
+ora_logoff is called.
+
+Solution:
+In my case, this was caused by a faulty oracle install. The install grabbed
+the wrong version of mergelib (The X11R6 one) instead of the one in
+$ORACLE_HOME/bin. Try a more limited path and reinstall Oracle again.
+
+-------------------------------------------------------------------------------
+Environment: SGI IRIX
+
+From Dennis Box <dbox@fndapl.fnal.gov>:
+
+Details instructions are available from http://misdev.fnal.gov/~dbox/n32/
+(To build IRIX n32 format using the Oracle n32 toolkit.)
+
+From Mark Duffield <duffield@ariad.com>: (possibly now out of date)
+
+Oracle only supports "-32" and "-mips2" compilation flags, not "-n32".
+Configure and build perl with -32 flag (see perl hints/irix_6.sh file
+in the perl distribution).
+Rebuild DBI (which will now use the -32 flag).
+Rebuild DBD::Oracle (which will now use the -32 flag).
+
+Since IRIX depends on the perl executable in /usr/sbin, you'll have to
+keep it around along with the one you just built. Some care will need
+to be taken to make sure that you are getting the right perl, either
+through explicitly running the perl you want, or with a file header in
+your perl file. The file header is probably the better solution of the two.
+
+In summary, until Oracle provides support for either the "-n32" or the "-64"
+compiler switches, you'll have to have a perl, DBI, and DBD-Oracle which are
+compiled and linked "-32". I understand that Oracle is working on a 64bit
+versions of V7.3.3 for SGI (or MIPS ABI as they call it), but I don't have
+any firm dates.
+
+You may also need to use perl Makefile.PL -p.
+
+-------------------------------------------------------------------------------
+Environment: 64-bit platforms (DEC Alpha, OSF, SGI/IRIX64 v6.4)
+
+Problem: 0 ORA-00000: normal, successful completion
+
+Solution: Add '#define A_OSF' to Oracle.h above '#include <oratypes.h>' and
+complain to Oracle about bugs in their header files on 64 bit systems.
+
+-------------------------------------------------------------------------------
+Link errors or test core dumps
+
+Try each of these in turn (follow each with a make && make test):
+ perl Makefile.PL -nob
+ perl Makefile.PL -c
+ perl Makefile.PL -l
+ 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:
+
+From: "Alexi S. Lookin" <aslookin@alfabank.ru>
+
+In short, this problem was solved after addition of parameter
+BEQUEATH_DETACH=YES in SQLNET.ORA and restarting Oracle instance.
+
+Browsed Net8 doc (A67440-01 Net8 Admin Guide for Oracle 8.1.5,
+Feb.1999) and found some mention of inadequate bequeath behaviour when
+disconnecting bequeath session, and some solution for this problem at
+page 10-15 (may vary at any other release) :
+
+"p.10-15
+Child Process Termination
+
+Since the client application spawns a server process internally through
+the Bequeath protocol as a child process, the client application
+becomes responsible for cleaning up the child process when it
+completes. When the server process completes its connection
+responsibilities, it becomes a defunct process. Signal handlers are
+responsible for cleaning up these defunct processes. Alternatively, you
+may configure your client SQLNET.ORA file to pass this process to the
+UNIX init process by disabling signal handlers.
+
+Use the Net8 Assistant to configure a client to disable the UNIX signal
+handler. The SQLNET.ORA parameter set to disable is as follows:
+ bequeath_detach=yes
+
+This parameter causes all child processes to be passed over to the UNIX
+init process (pid = 1). The init process automatically checks for
+"defunct" child processes and terminates them.
+
+Bequeath automatically chooses to use a signal handler in tracking
+child process status changes. If your application does not use any
+signal handling, then this default does not affect you."
+
+===============================================================================
+
+End.
Added: dbd-oracle/branches/pythian/README.hpux.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.hpux.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,1386 @@
+=head1 INTRODUCTION
+
+Building a working dynamically linked version of the Oracle DBD driver
+on HP-UX (11.00) has been a challenge for many. For months after taking
+a new job, where HP-UX was the standard database server environment, I
+had only been able to build a statically linked version of Perl and the
+DBD-Oracle module on HP-UX 11.00.
+
+Then Roger Foskett posted instructions for what turned out to be dynamic
+build. Rogers's post got me farther than I had previously gotten. In fact,
+after resolving some undefined symbol errors, I succeeded where for I had
+previously despaired of finding the time to hack out the right
+incantation.
+
+This F<README.hpux> describes the combined knowledge of a number of
+folks who invested many hours discovering a working set of build options.
+The instructions in this file, which include building Perl from
+source, will produce a working dynamically linked DBD-Oracle that can
+be used with mod_perl and Apache.
+
+See Appendices for exact build configurations used by me an others.
+
+For HPUX 11 on Itanium see also
+http://www.nntp.perl.org/group/perl.dbi.users/23840
+
+=head1 First things First: Introduction
+
+The reason you are even reading this file is because you want to connect
+to an Oracle database from your perl program using the DBD::Oracle DBI
+driver. So before you start, install (at least
+the Oracle client software) (SQL*Net, Pro*C, SQL*Plus) upon the machine you
+intend to install Perl/DBI/DBD-Oracle. You B<do not>, I repeat, I<do not> need
+to build a database on this machine.
+
+After you have installed the Oracle client software, B<test it!>. Make sure you
+can connect to the target database using SQL*Plus (or any other Oracle
+supplied tool). The (gory) details of the install are beyond the scope of
+this document, some information can be found in the section
+L<Compiling on a Client Machine>, or see your friendly Oracle DBA.
+
+One final remark, 3 years after this was first written. This has been
+updated numberous times over the years. And some of the new biuld
+recipe's see simpler than some of the original instructions in this file.
+
+I think one reason the recipe is getting simpler may be that the build
+hints, in the base perl build have gotten more right, as we have moved
+from perl 5.6.1 to the 5.8.4 (now the stable version). Its too bad they don't
+include the +z switch (at least for when the compiler is the softbench C
+compiler for the bundled C compiler.
+
+Someday, if I ever find myself building on HP again I should probably
+update as many of these recipes (that I can test) by trying to remove
+more of the special case stuff I have in my build scripts now.
+Gram Ludlows's build for the default bundled C compiler shows that a lot
+of this may no longer be necessary.
+
+On the other hand, it would be bad if we deleted information that others
+might need, so I err on the side of too much, in the hope that the
+person who really needs the information, will not have to look beyond
+this file.
+
+ -- Lincoln
+
+
+=head1 Build your own Perl
+
+HP's default Perl is no good (and antique).
+
+By default, HP-UX 11.00 delivered Perl 5.00503 until September 2001.
+Others tell me that the default is a threaded GNUpro build of 5.6.1.
+This is not what I found on our systems, and it probably depends on which
+packages you install. In any case, this version of Perl delivered by
+HP will in all likelihood not work. Before you check, be sure to prevent
+the perl4 located in /usr/contrib/bin from being the first Perl version
+found in your $PATH.
+
+As of application release September 2001, HP-UX 11.00 is shipped with
+Perl-5.6.1 in /opt/perl. The first occurrence is on CD 5012-7954. The
+build is a portable hppa-1.1 multithread build that supports large files
+compiled with gcc-2.9-hppa-991112. When you have a modern system with a
+hppa-2.0 architecture (PA8xxx processor) and/or the HP C-ANSI-C compiler
+consider building your own Perl, which will surely outperform this
+version.
+
+If you are reading this, you have probably discovered that something did
+not work. To get a working version of the DBD-Oracle driver, we have to start
+with a Perl that as been built with the correct compiler flags and shared
+libraries. This means that you must build your own version of Perl from
+source.
+
+See L<Appendix A> for a copy of a makefile used by me to build
+Perl on HP-UX and all other platforms on which he works (Sun and Red Hat).
+
+The instructions below have been used for building a dynamically linked
+working DBD-Oracle driver that works with mod_perl and Apache. These
+instructions are based on Perl 5.6.0 and 5.6.1, and 5.8.0.
+To this author's knowledge, they have not be tested on earlier versions of Perl.
+
+Note that is important to build a B<non>-threaded Perl, but linked with
+-lcl and -lpthread. Since Oracle on HP uses libpthread, everything that
+dynamically loads it (such as DBD-Oracle) must be built/linked
+with '-lpthread -lcl'. (When used with Apache, it and any associated
+modules must also be built this way - otherwise all it does is core
+dump when loading DBD::Oracle).
+
+A good link that explains thread local storage problems is
+http://my1.itrc.hp.com/cm/QuestionAnswer/1,1150,0x0d0a6d96588ad4118fef0090279cd0f9!0,00.html
+
+One more note, it would appear that the README.hpux in the Perl 5.8.0
+directory, is somewhat out of date (and is in the process of being updated
+by H.Merijn Brand, who points out that Perl I<is> 64bit compliant when
+the -Duse64bitall flag is used to Configure. While Perl will be built
+in a pure LP64 environment via the +DD64 flag is used, the +DA2.0w flag
+is preferred, and when an incantation can be concocted that eliminates
+the noisy warnings the produces at link time, this will probably become
+the default. Older 64bit versions of GCC, are known to be unable to
+build a good LP64 perl. And these flags will cause gcc to barf.
+
+=head1 Compilers
+
+=head2 HP Softbench Compiler
+
+Both Roger Foskett, I and most others have been using the HP Softbench
+C compiler normally installed in:
+
+ /opt/softbench/bin/cc.
+
+While the DBD-Oracle F<Makefile.PL> checks for some of the
+conditions which, when met, we know will produce a working build,
+there are many variations of Oracle installations and
+features. Not all of these can be tested by any one of us,
+if you discover a way to make a variation which did not previously
+work, please submit patches to the Makefile.PL to Tim Bunce, and
+patches to this README to me, and I will incorporate them into the
+next README.
+
+The instructions herein, have compiled, linked cleanly, and tested
+cleanly using the HP softbench compiler, and Oracle 8.0.5 (32bit), and
+Oracle 8.1.6, 8.1.7 (64 bit). Oracle 8.1.5 will probably work as well.
+
+Oracle 8.1.7.4 (32bit) with DBI-1.35 and DBD-Oracle-1.13 has been proven
+to work on HP-UX 11.00 (64bit) with Perl 5.6.1, Perl 5.8.x
+using the guidelines in this document for both HP-C-ANSI-C and gcc-3.2. Later
+versions have been proven to work as well. Current DBI-1.42 and DBD-Oracle-1.16
+have been proven to work. This Oracle 9.2 client (at least) should be used if you
+plan to do work with Unicode. See the DBD-Oracle POD/Man documentation.
+
+=head2 gcc Compiler
+
+For along time many folks have asked, how they could build a DBD-Oracle
+perl using the gcc compiler, and while some had claimed to have done it,
+none were forth coming with precise (and repeatable) instructions for
+doing so.
+
+Recently, Waldemar Zurowski and Michael Schuh sent useful information
+about builds of Perl with DBD-Oracle using gcc on HP-UX. Both were able
+to get working executables, and their explanations shed much light on
+the issues.
+
+Waldemar's build is described in L<Appendix B>, and Michael's is
+described in L<Appendix D>.
+
+While I have not reproduced either of these configurations, I
+believe the information is complete enough (particularly in the
+aggregate) to be helpful to others who might wish to replicate it.
+
+If someone would be willing to submit a makefile equivalent to
+the makefile in Appendix A, which uses gcc to build Perl and the
+DBI/DBD-Oracle interfaces, I will be happy to include it in the next
+README.
+
+=head2 The "default" built in compiler 64bit build (/usr/bin/cc)
+
+And now, at long last, we have a recipe for building perl and DBD-Oracle
+using the default bundled C compiler. Please see the Appendix C build
+instructions provided by Gram Ludlow, using the default /usr/bin/cc
+bundled compiler.
+
+=head2 Just tell me the recipe...
+
+If you are using the softbench compiler, just copy and modify my makefile.
+A copy of this makefile, which I use to build Perl and the DBI interfaces
+(and all other modules I use for that matter) on all platforms (HP, SUN
+and Red Hat) can be found in L<Appendix A>. If you want to skip reading
+the rest of this screed, try copying the makefile into a directory where
+you have all your compressed tar balls, editing the macros at the top,
+and running make.
+
+It you are plan to give gcc a go, consider making modifications
+to this makefile, and sending it back to me, as a GCC example.
+
+=head2 Configure (doing it manually)
+
+Once you have downloaded and unpacked the Perl sources (version 5.6.1
+assumed here), you must configure Perl. For those of you new to building
+Perl from source, the Configure program will ask you a series of questions
+about how to build Perl. You may supply default answers to the questions
+when you invoke the Configure program by command line flags.
+
+We want to build a Perl that understands large files (over 2GB),
+and that is incompatible with v5.005 Perl scripts (compiling with v5.005
+compatibility causes mod_perl to complain about malloc pollution). At the
+command prompt type:
+
+ cd perl-5.6.1/
+ ./Configure -Ubincompat5005 -Duselargefiles
+
+As described in the section "Building the right Perl", there are some
+modifications you must make during the Configure process... so,
+when asked the question:
+
+ What libraries to use? - Answer by prepending (i.e. at the beginning): -lcl -lpthread
+
+ For example:
+ What libraries to use? [-lnsl -lnm -lndbm -lmalloc -ldld -lm -lc -lndir -lcrypt -lsec] -lcl -lpthread -lnsl -lnm -lndbm -lmalloc -ldld -lm -lc -lndir -lcrypt -lsec
+
+H.Merijn Brand notes that the above can be accomplished by adding the
+following to the ./Configure command line:
+
+ -A prepend:libswanted='cl pthread '
+
+Do not forget the space before the trailing quote. Also note that this
+does not (yet) work with 64bit versions of GCC.
+
+I use this in my standard build now. (See L<Appendix A>)
+
+When asked:
+
+ Any additional cc flags? - Answer by prepending: +z
+
+ For example:
+ Any additional cc flags? [-D_HP-UX_SOURCE -Aa] +z -D_HP-UX_SOURCE -Aa
+
+Lastly, and this is optional, when asked:
+
+ Do you want to install Perl as /usr/bin/perl? [y] n
+
+ You may or may not want to install directly in /usr/bin/perl,
+ many persons on HP install Perl in /opt/perl<version>/bin/perl and
+ put a symbolic link to /usr/bin/perl. Furthermore, you can supply
+ the answer to this question by adding an additional switch to the
+ invocation of Configure such as: Configure -Dprefix=/opt/perl
+
+After you have answered the above questions, accept the default values for all
+of the remaining questions. You may press <Enter> for each remaining
+question, or you may enter "& -d" (good idea) at the next question and
+the Configure will go into auto-pilot and use the Perl supplied defaults.
+
+BTW: If you add -lcl and -lpthread to the end of the list it will not
+work. I wasted a day and a half trying to figure out why I had lost the
+recipe, before I realized that this was the problem. The symptom will
+be that
+
+ make test
+
+of Perl itself will fail to load dynamic libraries.
+
+You can check in the generated 'config.sh' that the options you selected
+are correct. If not, modify config.sh and then re-run ./Configure with
+the '-d' option to process the config.sh file.
+
+Build & Install
+
+
+ make
+ make test
+ make install
+
+If you are going to build mod_perl and Apache it has been suggested
+that you modify Config.pm to the change the HP-UX ldflags & ccdlflags in
+F</your/install/prefix/lib/5.6.0/PA-RISC2.0/Config.pm> as follows:
+
+ ccdlflags=''
+ cccdlflags='+z'
+ ldflags=' -L/usr/local/lib'
+
+This is not necessary if you are not using mod_perl and Apache.
+
+=head1 Build and Install DBI
+
+
+ cd DBI-1.35/
+ Perl Makefile.PL
+ make
+ make test
+ make install
+
+=head1 Build and Install DBD-Oracle-1.07 and later
+
+It is critical to setup your Oracle environmental variables. Many people
+do this incorrectly and spend days trying to get a working version of
+DBD-Oracle. Below are examples of a local database and a remote database
+(i.e. the database is on a different machine than your Perl/DBI/DBD
+installation) environmental variable setup.
+
+Example (local database):
+
+ export ORACLE_USERID=<validuser/validpasswd>
+ export ORACLE_HOME=<path to oracle>
+ export ORACLE_SID=<a valid instance>
+ export SHLIB_PATH=$ORACLE_HOME/lib #for 32bit HP
+ export LD_LIBRARY_PATH=$ORACLE_HOME/lib #for 64bit HP (I defined them both)
+
+Example (remote database):
+
+ export ORACLE_USERID=<validuser/validpasswd>
+ export ORACLE_HOME=<path to oracle>
+ export ORACLE_SID=@<valid tnsnames.ora entry>
+ export SHLIB_PATH=$ORACLE_HOME/lib #for 32bit HP
+ export LD_LIBRARY_PATH=$ORACLE_HOME/lib #for 64bit HP (I defined them both)
+
+The standard mantra now works out of the box on HP-UX:
+
+ cd DBD-1.07/ #or more recent version
+ perl Makefile.PL
+ make
+ make test
+ make install # if all went smoothly
+
+And with DBD-1.14 and later the following can be used:
+
+ cd DBD-1.14 / #or more recent version
+ perl Makefile.PL -l # uses a simple link to oracle's main library
+ make
+ make test
+ make install # if all went smoothly
+
+
+If you have trouble, see the L<Trouble Shooting> instructions below, for hints
+of what might be wrong... and send me a note, describing your
+configuration, and what you did to fix it.
+
+=head1 Trouble Shooting
+
+=head2 "Unresolved symbol"
+
+In general, find the symbols, edit the Makefile, and make test.
+
+You'll have to modify the recipe accordingly, in my case the symbol
+"LhtStrCreate" was unresolved. (Authors Note: thanks patch suggestions
+by Jay Strauss this situation which occurs with Oracle 8.1.6 should
+now be handled in Makefile.PL.)
+
+1) Find the symbols.
+
+ a) The following ksh/bash code (courtesy of Roger) will search
+ from $ORACLE_HOME and below for Symbols in files in lib directories.
+ Save the following to a file called "findSymbol".
+
+ >>>> CUT HERE <<<<<
+ cd $ORACLE_HOME
+
+ echo "\nThis takes a while, grepping a lot of stuff"
+ echo " ignore the \"no symbols\" warnings\n"
+
+ sym=$1; shift;
+ libs="*.sl"
+
+ for lib in $(find . -name $libs -print); do
+ if nm -p $lib | grep -q $sym; then
+ echo "found \"$sym\" in $lib"
+ fi
+ done
+ >>>>> CUT HERE <<<<
+
+ b) Run it (replace "LhtStrCreate" with your "Unresolved symbol"). For
+ example, at my installation, findSymbols produced the following output:
+
+ # chmod 755 findSymbols
+ # ./findSymbol LhtStrCreate
+
+ found "LhtStrCreate" in ./lib/libagtsh.sl
+ found "LhtStrCreate" in ./lib/libclntsh.sl
+ found "LhtStrCreate" in ./lib/libwtc8.sl
+
+2) Edit the Makefile
+
+In the previous step your unresolved symbol was found in one or more
+library files. You will need to edit the OTHERLDFLAGS makefile macro,
+and add the missing libraries.
+
+When you add those library files to OTHERLDFLAGS you must convert the
+name from the actual name to the notation that OTHERLDFLAGS uses.
+
+ libclntsh.sl becomes => -lclntsh
+ libagtsh.sl becomes => -lagtsh
+ libwtc8.sl becomes => -lwtc8
+
+That is, you replace the "lib" in the name to "-l" and remove the ".sl"
+
+You can edit the Makefile in 2 ways:
+
+ a) Do this:
+
+ cat Makefile | sed 's/\(OTHERLDFLAGS.*$\)/\1 -lclntsh/' > Makefile.tmp
+ mv Makefile.tmp Makefile
+
+ b) Using vi, emacs... edit the file, find OTHERLDFLAGS, and add the
+ above "-l" entries to the end of the line.
+
+ For example the line:
+ OTHERLDFLAGS = -L/opt/oracle/product/8.1.6/lib/... -lqsmashr
+
+ Becomes:
+ OTHERLDFLAGS = -L/opt/oracle/product/8.1.6/lib/... -lqsmashr -lclntsh
+
+3) make test
+
+Perform a make test, if symbols are still unresolved repeat the editing of
+the Makefile and make test again.
+
+=head1 DBD-Oracle-1.06
+
+You are strongly urged to upgrade. However here is what you may
+need to know to get it or work, if you insist on using an earlier
+version.
+
+Check the output that above command produces, to verify that
+
+ -Wl,+n
+ -W1,+s
+
+is b<NOT> present. and that
+
+ -lqsmashr
+
+B<is> present.
+
+If the version of Makefile.PL does not include the patch produced at the time
+of this README.hpux, then the above conditions will likely not be met.
+You can fix this as follows:
+
+ cat Makefile | sed 's/-Wl,+[sn]//' > Makefile.tmp
+ mv Makefile.tmp Makefile
+
+
+=head1 Building on a Oracle Client Machine
+
+If you need to build or deliver the DBD-Oracle interface on or to
+a machine upon which the Oracle database has not been installed
+you need take the following into consideration:
+
+=over
+
+=item 1) Oracle files are needed for DBD::Oracle to compile
+
+=item 2) Oracle files are needed for the compiled DBD to connect
+
+=item 3) ORACLE_HOME environment variable must be set
+
+=item 4) SHLIB_PATH environment variable must be set
+
+=back
+
+=head2 Compiling on a Client Machine
+
+This may seem obvious to some, but the Oracle software has to be
+present to compile and run DBD-Oracle. The best way to compile and
+install on a client machine, is to use the oracle installer
+to install the oracle (client) software locally. Install SQL*Net, Pro*C
+and SQL*Plus. After this some tests with SQL*Net (tnsping at a minimum)
+are an good idea. Make sure you can connect to your remote database,
+and everything works with Oracle before you start bashing your head into
+the wall trying to get DBD-Oracle to work.
+
+If you do not have the Oracle installer handy, the following hack has been
+known to work:
+
+Either open an NFS share from the oracle installation directory on the
+machine that has Oracle and point both of the above-mentioned env vars to
+that share, or alternatively copy the following four directories from your
+Oracle installation over to the machine on which you are compiling the DBD:
+
+drwxr-xr-x 3 oracle dba 3072 Jul 3 09:36 lib
+drwxr-xr-x 13 oracle dba 512 Jul 3 09:38 network
+drwxr-xr-x 7 oracle dba 512 Jul 2 19:25 plsql
+drwxr-xr-x 12 oracle dba 512 Jul 3 09:38 rdbms
+
+then point the above-mentioned env vars to the containing directory (good
+place to put them, if copying locally, might be /usr/lib/oracle,
+/usr/local/lib/oracle, or /opt/oracle/lib )
+
+In any case, the compiler needs to be able to find files in the above four
+directories from Oracle in order to get all the source code needed to
+compile properly.
+
+=head2 Required Runtime environment
+
+Again, use the Oracle installer to install the Oracle Client on the machine
+where your scripts will be running. If the Oracle installer is not available,
+the following hack should suffice:
+
+For running the compiled DBD in Perl and connecting, you need only the
+files in the 'lib' folder mentioned above, either connecting to them through
+an NFS share on the Oracle machine, or having copied them directly onto the
+local machine, say, in /usr/lib/oracle . Make sure the env variable for
+ORACLE_HOME = /usr/lib/oracle and LD_LIBRARY_PATH includes /usr/lib/oracle .
+You can set the env var in your perl script by typing
+
+$ENV{'ORACLE_HOME'} = '/usr/lib/oracle';
+
+=head1 Apache and mod_perl
+
+B<Nota Bene:> these instructions are now more than a year and a half old,
+you may have to tinker.
+
+If you are not building this version of Perl for Apache you can go on
+to build what ever other modules you require. The following instructions
+describe how these modules were built with the Perl/DBD-Oracle built above:
+The following is what worked for Roger Foskett:
+
+
+=head1 Apache Web server
+
+ cd apache_1.3.14/
+ LDFLAGS_SHLIB_EXPORT="" \
+ LDFLAGS="-lm -lpthread -lcl" \
+ CC=/usr/bin/cc \
+ CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
+ ./configure \
+ --prefix=/opt/www/apache \
+ --enable-shared=max \
+ --disable-rule=EXPAT \
+ --enable-module=info \
+ --enable-rule=SHARED_CORE
+
+The Expat XML parser is disabled as it conflicts with the Perl
+XML-Parser module causing core dumps. -lcl is needed to ensure that Apache does
+not coredump complaining about thread local storage
+
+ make
+ make install
+
+Once installed, ensure that the generated httpd.conf is properly
+configured, change the relevant lines to below (the default user/group
+caused problems on HP (the user 'www' may need to be created)
+
+ User www
+ Group other
+ port 80
+
+=head2 mod_perl
+
+ cd mod_perl-1.24_01/
+ perl Makefile.PL \
+ NO_HTTPD=1 \
+ USE_APXS=1 \
+ WITH_APXS=/opt/www/apache/bin/apxs \
+ EVERYTHING=1
+ make
+ make install
+
+=head2 htdig intranet search engine
+
+ cd htdig-3.1.5/
+ CC='cc' CPP='aCC' \
+ ./configure \
+ --prefix=/opt/www/htdig \
+ --with-cgi-bin-dir=/opt/www/htdig/cgi-bin \
+ --with-image-dir=/opt/www/htdig/images
+
+=head1 CONTRIBUTORS
+
+The following folks contributed to this README:
+
+ Lincoln A. Baxter <lab@lincolnbaxter.com.Fix.This>
+ Jay Strauss <me@heyjay.com.Fix.This>
+ Roger Foskett <Roger.Foskett@icl.com.Fix.This>
+ Weiguo Sun <wesun@cisco.com.Fix.This>
+ Tony Foiani <anthony_foiani@non.hp.com.Fix.This>
+ Hugh J. Hitchcock <hugh@hitchco.com.Fix.This>
+ Heiko Herms <Heiko.Herms.extern@HypoVereinsbank.de.Fix.This>
+ Waldemar Zurowski <bilbek0@poczta.onet.pl.Fix.This>
+ Michael Schuh <Michael.Schuh@airborne.com.Fix.This>
+ H.Merijn Brand <h.m.brand@hccnet.nl.Fix.This>
+ Gram M. Ludlow <LUDLOW_GRAM_M@cat.com.Fix.This>
+
+And probably others unknown to me.
+
+=head1 AUTHOR
+
+ Lincoln A. Baxter
+ <lab@lincolnbaxter.com.Fix.This>
+
+=head1 Appendix A (Lincoln's makefile)
+
+The following is the text of the makefile I use to build Perl on all platforms
+I run on. If you paste this to a text file, remember to remove leading blanks from
+the target lines, and replace leading blanks on the rule lines with TAB characters.
+
+
+ # 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
+
+
+
+=head1 Appendix B (gcc build info from Waldemar Zurowski)
+
+This is pretty much verbatim the build information I received from Waldemar Zurowski
+on building Perl and DBD-Oracle using gcc on HP. Note that this build was on
+a PA-RISC1.1 machine. Differences for building on PA-RISC2.0 would be welcome and
+incorporated into the next README.
+
+=head2 Host
+
+ HP-UX hostname B.11.11 U 9000/800 XXXXXXXXX unlimited-user license
+
+=head2 Oracle
+
+ Oracle 8.1.7
+
+=head2 Parameters to build Perl
+
+ ./Configure -des -Uinstallusrbinperl -Uusethreads -Uuseithreads
+ -Duselargefiles -Dcc=gcc -Darchname=PA-RISC1.1 -Dprefix=/opt/perl-non-thread
+ -Dlibs='-lcl -lpthread -L${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads
+ -ljava -lnsl -lnm -lndbm -ldld -lm -lc -lndir -lcrypt -lsec'
+
+-L${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads -ljava, was added
+because DBD::Oracle wants to link with it (probably due to Oracle's own
+build rules picked up by Makefile.PL)
+
+Set environment variable LDOPTS to '+s' (see ld(1)). This holds
+extra parameters to HP-UX's ld command, as I don't use GNU ld (does anybody?).
+This allows you to build an executable, which when run would search for
+dynamic linked libraries using SHLIB_PATH (for 32-bit executable)
+and LD_LIBRARY_PATH (for 64-bit executable). Obviously LDOPTS is
+needed only when building Perl _and_ DBI + DBD::Oracle.
+
+Then, after building Perl + DBI + DBD::Oracle and moving it
+into production environment it was enough to add to SHLIB_PATH
+${ORACLE_HOME}/lib and ${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads,
+for example:
+
+SHLIB_PATH=${ORACLE_HOME}/lib:${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads:
+$SHLIB_PATH
+
+Please note output of ldd command:
+
+ $ ldd -s ./perl
+ [...]
+ find library=/home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl;
+ required by ./perl
+ search path=/home/ora817/lib:/home/ora817/JRE/lib/PA_RISC/native_threads
+ (SHLIB_PATH)
+ trying path=/home/ora817/lib/libjava.sl
+ trying path=/home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl
+ /home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl =>
+ /home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl
+ [...]
+
+All of this mess is necessary because of weakness of shl_load(3X),
+explained in current README.hpux and in some discussion forums at HP.com
+site. I have learned, that HP issued patch PHSS_24304 for HP-UX 11.11
+and PHSS_24303 for HP-UX 11.00, which introduced variable LD_PRELOAD.
+I haven't tried it yet, but it seems promising that it would allow you
+to completely avoid building your own Perl binary, as it would be enough
+to set LD_PRELOAD to libjava.sl (for example) and all 'Cannot load XXXlibrary'
+during building of DBD::Oracle should be gone.
+
+The documentation says, that setting this variable should have the same
+effect as linking binary with this library. Also please note, that this
+variable is used only when binary is not setuid nor setgid binary (for
+obvious security reasons).
+
+It seems, that the best way to find out if you already have this patch
+applied, is to check if 'man 5 dld.sl' says anything about LD_PRELOAD
+environment variable.
+
+Best regards,
+
+Waldemar Zurowski
+
+Authors Note: Search for references to LD_PRELOAD else where in this
+document. Using LD_PRELOAD is probably a fragile solution at best. Better
+to do what Waldemar actually did, which is to include libjava in the extra
+link options.
+
+=head1 Appendix C (64 bit build with /usr/bin/cc -- bundled C compiler)
+
+Gram M. Ludlow writes:
+
+I recently had a problem with Oracle 9 64-bit on HPUX 11i. We have another
+application that required SH_LIBARY_PATH to point to the 64-bit libraries,
+which "broke" the Oraperl module. So I did some research and successfully
+recompiled and re-installed with the most recent versions of everything
+(perl, DBI, DBD) that works with 64-bit shared libraries. This is the error
+we were getting (basically)
+"/usr/lib/dld.sl: Bad magic number for shared library:
+/ora1/app/oracle/product/9.2.0.1.0/lib32"
+
+Here is my step-by-step instructions, pretty much what you have but
+streamlined for this particular case.
+
+Required software:
+
+ HPUX 11.11 (11i) PA-RISC
+ perl 5.8.4 source
+ DBI-1.42 source
+ DBD-Oracle-1.16 source
+ Oracle 9.2.0.1.0 installation
+
+=over
+
+=item Step 1: Compiling Perl
+
+This compiles PERL using the default HPUX cc compiler. The important things
+to note here are the configure parameters. the only non-default option to
+take is to add "+z" to the additional cc flags step.
+
+ gunzip perl-5.8.4.tar.gz
+ tar -xf perl-5.8.4.tar
+ cd perl-5.8.4
+ ./Configure -Ubincompat5005 -Duselargefiles -A prepend:libswanted='cl pthread ' -Duse64bitall
+
+Any additional cc flags?
+Add +z to beginning of list, include all other options.
+
+ make;make test
+
+98% of tests should succeed. If less, something is wrong.
+
+=item Step 2: DBI
+
+ gunzip DBI-1.42.tar.gz
+ tar -xvf DBI-1.42.tar
+ cd DBI-1.42
+ perl Makefile.PL
+ make;make test
+ make install
+
+=item Step 3: Install DBD-Oracle
+
+First, set the following environment variables specific you your Oracle
+installation:
+
+ export ORACLE_USERID=user/pass
+ export ORACLE_HOME=/oracle/product/9.2.0.1.0
+ export ORACLE_SID=orap1
+
+Then unpack and build:
+
+ gunzip DBD-Oracle-1.16.tar.gz
+ tar -xvf DBD-Oracle-1.16.tar
+ cd DBD-Oracle-1.16
+ perl Makefile.PL -l
+ make;make test
+ make install
+
+=back
+
+=head1 Appendix D (Miscellaneous links which might be useful)
+
+Michael Schuh writes:
+
+It was a bit by trial and error and a bit more by following your
+suggestions (and mapping them to gcc) that I got something that worked.
+
+One of the most significant "mappings" was to take your suggestion under
+"Configure" to add "+z" to the ccflags variable and to change that to
+"-fPIC" (which, I learned from the gcc man page, is different than
+"-fpic" - I'm not sure if this is a significant difference, and, no, I
+don't want to experiment!).
+
+I suspect that your hint about adding -lcl and -lpthread were crucial,
+but (after doing so) I never encountered any problems that were related
+to them.
+
+One thing that I did was create a shell script to set some variables,
+as the initial environment for root on the target system didn't work
+very well. Here is that script, trimmed to remove a bunch of echo
+statements, etc.:
+
+ # -------------------------------------------------------------------
+ # root.env - sets some environment variables the way I want them...
+ #
+ # Mike Schuh, June 2002, July 2002
+
+ export CC=/usr/local/bin/gcc
+
+ export INSTALL=./install-sh
+
+ . appl_setup DDD
+
+ export ORACLE_SID="SSS"
+ export ORACLE_USERID="XXX/YYY"
+
+ export PATH=/usr/local/bin:/usr/sbin:/usr/bin:/usr/ccs/bin:/opt/perl5/bin:/usr/c
+ ontrib/bin:/opt/nettladm/bin:/opt/fc/bin:/opt/fcms/bin:/opt/pd/bin:/usr/bin/X11:
+ /usr/contrib/bin/X11:/opt/hparray/bin:/opt/resmon/bin:/usr/sbin/diag/contrib:/op
+ t/pred/bin:/opt/gnome/bin:/sbin
+
+ # end of root.env
+
+The appl_setup sets some Oracle variables (specific to our installation),
+which I then override for the database that I am working on. The script
+(which I source) also unse some variables specific to other applications
+(e.g., Tivoli), mostly to unclutter my debugging. The INSTALL variable
+is related to building libgdbm.
+
+Here is the output of perl -V:
+
+ $ perl -V
+ Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
+ Platform:
+ osname=hpux, osvers=11.00, archname=PA-RISC1.1
+ uname='hp-ux SYSTEMNAME b.11.00 a 9000800 2002134832 two-user license '
+ config_args='-Ubincompat5005 -Dcc=gcc -Duselargefiles'
+ hint=previous, useposix=true, d_sigaction=define
+ usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
+ useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
+ use64bitint=undef use64bitall=undef uselongdouble=undef
+ Compiler:
+ cc='gcc', ccflags ='-D_HPUX_SOURCE -L/lib/pa1.1 -DUINT32_MAX_BROKEN -fno-strict-aliasing -I/usr/local/include -fPIC',
+ optimize='-O',
+ cppflags='-D_HPUX_SOURCE -L/lib/pa1.1 -DUINT32_MAX_BROKEN -fno-strict-aliasing -I/usr/local/include -fPIC'
+ ccversion='', gccversion='3.0.4', gccosandvers='hpux11.00'
+ intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
+ d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
+ ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
+ alignbytes=8, usemymalloc=y, prototype=define
+ Linker and Libraries:
+ ld='ld', ldflags =' -L/usr/local/lib'
+ libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
+ libs=-lcl -lpthread -lnsl -lnm -lndbm -lgdbm -ldld -lm -lc -lndir -lcrypt -lsec
+ perllibs=-lcl -lpthread -lnsl -lnm -ldld -lm -lc -lndir -lcrypt -lsec
+ libc=, so=sl, useshrplib=false, libperl=libperl.a
+ Dynamic Linking:
+ dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
+ cccdlflags='-fPIC', lddlflags='-b -L/usr/local/lib'
+
+ Characteristics of this binary (from libperl):
+ Compile-time options: USE_LARGE_FILES
+ Built under hpux
+ Compiled at Jul 18 2002 15:28:03
+ @INC:
+ /usr/local/lib/perl5/5.6.1/PA-RISC1.1
+ /usr/local/lib/perl5/5.6.1
+ /usr/local/lib/perl5/site_perl/5.6.1/PA-RISC1.1
+ /usr/local/lib/perl5/site_perl/5.6.1
+ /usr/local/lib/perl5/site_perl
+ .
+
+=head2 http://www.mail-archive.com/dbi-users@perl.org/msg18687.html
+
+Garry Ferguson's notes on a successful build using perl 5.8.0, DBI-1.38 and
+DBD-Oracle-1.14 on HPUX 11.0 ( an L2000 machine ) with Oracle 9.0.1
+
+=head2 http://www.sas.com/service/techsup/unotes/SN/001/001875.html
+
+This is a not from from the SAS support people documenting the LhtStrInsert()
+and LhtStrCreate() undefined symbols errors, and how to fix them in the
+Oracle makefiles.
+
+=head1 Appendix E (Perl Configuration Dumps)
+
+The following to sections provide full dumps of perl -V for three
+versions of Perl that were successfully built and linked on
+HP-UX 11.00.
+
+=head2 Lincoln Baxter's DBD-Oracle-1.07 Configuration
+
+ Platform:
+ osname=hpux, osvers=11.11, archname=PA-RISC2.0
+ uname='hp-ux dhas116 b.11.11 u 9000800 1509760598 unlimited-user license '
+ config_args='-Dprefix=/opt/perl/5.6.1-fccs-02 -Ubincompat5005 -Uuselargefiles \
+ -A eval:libswanted=\"cl pthread $libswanted\" -des'
+ hint=recommended, useposix=true, d_sigaction=define
+ usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
+ useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
+ use64bitint=undef use64bitall=undef uselongdouble=undef
+ Compiler:
+ cc='cc', ccflags ='-D_HP-UX_SOURCE -Aa',
+ optimize='-O',
+ cppflags='-D_HP-UX_SOURCE -Aa'
+ ccversion='B.11.11.02', gccversion='', gccosandvers=''
+ intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
+ d_longlong=undef, longlongsize=, d_longdbl=define, longdblsize=16
+ ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
+ alignbytes=8, usemymalloc=y, prototype=define
+ Linker and Libraries:
+ ld='ld', ldflags =' -Wl,+vnocompatwarnings -L/usr/local/lib -L/opt/gnu/lib'
+ libpth=/usr/local/lib /opt/gnu/lib /lib /usr/lib /usr/ccs/lib
+ libs=-lcl -lpthread -lnsl -lnm -lndbm -ldld -lm -lc -lndir -lcrypt -lsec
+ perllibs=-lcl -lpthread -lnsl -lnm -ldld -lm -lc -lndir -lcrypt -lsec
+ libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a
+ Dynamic Linking:
+ dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
+ cccdlflags='+z', lddlflags='-b +vnocompatwarnings -L/usr/local/lib -L/opt/gnu/lib'
+
+
+ Characteristics of this binary (from libperl):
+ Compile-time options:
+ Built under hpux
+ Compiled at Feb 26 2002 22:05:51
+ %ENV:
+ PERL5LIB="/home/baxtlinc/local/lib:/home/baxtlinc/perl/lib"
+ @INC:
+ /home/baxtlinc/local/lib
+ /home/baxtlinc/perl/lib
+ /opt/perl/5.6.1-fccs-02/lib/5.6.1/PA-RISC2.0
+ /opt/perl/5.6.1-fccs-02/lib/5.6.1
+ /opt/perl/5.6.1-fccs-02/lib/site_perl/5.6.1/PA-RISC2.0
+ /opt/perl/5.6.1-fccs-02/lib/site_perl/5.6.1
+ /opt/perl/5.6.1-fccs-02/lib/site_perl
+
+
+=head2 Lincoln Baxter's DBD-Oracle-1.06 Configuration
+
+ Platform:
+ osname=hpux, osvers=11.00, archname=PA-RISC2.0
+ uname='hp-ux dhdb108 b.11.00 u 9000800 612309363 unlimited-user license '
+ config_args='-Dprefix=/temp_data/baxtlinc/perl -Ubincompat5005'
+ hint=previous, useposix=true, d_sigaction=define
+ usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
+ useperlio=undef d_sfio=undef uselargefiles=define
+ use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
+ Compiler:
+ cc='cc', optimize='-O', gccversion=
+ cppflags='-D_HP-UX_SOURCE -I/usr/local/include +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae'
+ ccflags ='-D_HP-UX_SOURCE -I/usr/local/include +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae'
+ stdchar='unsigned char', d_stdstdio=define, usevfork=false
+ intsize=4, longsize=4, ptrsize=4, doublesize=8
+ d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
+ ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
+ alignbytes=8, usemymalloc=y, prototype=define
+ Linker and Libraries:
+ ld='ld', ldflags =' -Wl,+vnocompatwarnings'
+ libpth=/lib /usr/lib /usr/ccs/lib
+ libs=-lnsl -lnm -lndbm -ldld -lm -lc -lndir -lcrypt -lsec -lcl -lpthread
+ libc=, so=sl, useshrplib=true, libperl=libperl.sl
+ Dynamic Linking:
+ dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
+ cccdlflags='+z', lddlflags='-b +vnocompatwarnings'
+
+ Characteristics of this binary (from libperl):
+ Compile-time options: USE_LARGE_FILES
+ Built under hpux
+ Compiled at Jan 9 2001 17:36:00
+ @INC:
+ /temp_data/baxtlinc/perl/lib/5.6.0/PA-RISC2.0
+ /temp_data/baxtlinc/perl/lib/5.6.0
+ /temp_data/baxtlinc/perl/lib/site_perl/5.6.0/PA-RISC2.0
+ /temp_data/baxtlinc/perl/lib/site_perl/5.6.0
+ /temp_data/baxtlinc/perl/lib/site_perl
+ .
+
+
+=head2 Roger Foskett's Configuration (works with Apache and mod_perl)
+
+ Platform:
+ osname=hpux, osvers=11.00, archname=PA-RISC2.0
+ uname='hp-ux titan b.11.00 u 9000800 103901567 unlimited-user license '
+ config_args='-Ubincompat5005'
+ hint=recommended, useposix=true, d_sigaction=define
+ usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
+ useperlio=undef d_sfio=undef uselargefiles=define
+ use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
+ Compiler:
+ cc='cc', optimize='-O', gccversion=
+ cppflags='-D_HP-UX_SOURCE -Aa -I/usr/local/include'
+ ccflags =' +z -D_HP-UX_SOURCE -I/usr/local/include -D_LARGEFILE_SOURCE
+ -D_FILE_OFFSET_BITS=64 -Ae '
+ stdchar='unsigned char', d_stdstdio=define, usevfork=false
+ intsize=4, longsize=4, ptrsize=4, doublesize=8
+ d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
+ ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
+ lseeksize=8
+ alignbytes=8, usemymalloc=y, prototype=define
+ Linker and Libraries:
+ ld='ld', ldflags =' -L/usr/local/lib'
+ libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
+ libs=-lnsl -lnm -lndbm -lgdbm -ldld -lm -lc -lndir -lcrypt -lsec -lcl
+ -lpthread
+ libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a
+ Dynamic Linking:
+ dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags=' '
+ cccdlflags='+z', lddlflags=' -b +vnocompatwarnings -L/usr/local/lib'
+
+ Characteristics of this binary (from libperl):
+ Compile-time options: USE_LARGE_FILES
+ Built under hpux
+ Compiled at Dec 19 2000 19:17:00
+ @INC:
+ /opt/www/perl5/lib/5.6.0/PA-RISC2.0
+ /opt/www/perl5/lib/5.6.0
+ /opt/www/perl5/lib/site_perl/5.6.0/PA-RISC2.0
+ /opt/www/perl5/lib/site_perl/5.6.0
+ /opt/www/perl5/lib/site_perl
+ .
+
+
+Roger also provides a link to some threads containing some of his
+DBD-Oracle and HP-UX 11 trials...
+L<http://www.geocrawler.com/search/?config=183&words=Roger+Foskett>
+
+
+=head1 Appendix F (Why Dynamic Linking)
+
+Some one posted to the DBI email list the following question:
+
+ What are the advantages of building a dynamically linked version?
+ Being able to use threads? Or something besides that?
+
+The answer is there are too many to count, but here are several big
+ones:
+
+=over
+
+=item 1 Much smaller executables
+
+Only the code referenced gets loaded... this
+means faster execution times, and less machine resources (VM) used)
+
+=item 2 Modular addition and updating of modules.
+
+This is HUGE. One does not relink B<EVERYTHING, EVERY time> one changes
+or updates a module.
+
+=item 3 It eliminates Dynaloader warning (multiply defined).
+
+This occurs with the static build when Perl is run with -w. I fixed
+this by removing -w from my #! lines, converting the the pragam "use
+warnings;". However, it was annoying, since all my scripts had -w in the
+#! line.
+
+=item 4 It's the default build
+
+Since almost every OS now supports dynamic linking, I believe that
+static linking is NOT getting the same level of vetting it maybe used
+to. Dynamicly linking is what you get by default, so its way better
+tested.
+
+=item 5 It's required for Apache and mod_perl.
+
+=back
+
+=head1 Appendix G (RE problem with libjava.sl)
+
+The following is a message I received from Jon Stevenson concerning a
+problem with the libjava.sl. Note that the gcc build described in
+L<Appendix B> also describes a problem with libjava.sl, which was solved
+by putting it in the extra libraries option at configure time. That is
+probably a preferable solution.
+
+
+ -----Original Message-----
+ From: Stevenson, Jonathan [mailto:Jonathan.Stevenson@infores.com.Fix.This]
+ Sent: Wednesday, March 27, 2002 6:31 AM
+ To: LBaxter@FLEETCC.COM.Fix.This
+ Cc: dbi_users@perl.org
+ Subject: RE: Error on make for DBD-Oracle 1.12 on HP-UX 11.0
+
+ Hi Lincoln,
+
+ Thanks for your help with this. We now have a working installation,
+ although we still do have some issues to resolve still. The problem
+ seems to be the libjava.sl library. Running the make test step
+ generated this message: Can't shl_load() a library containing Thread
+ Local Storage.
+
+ We have got round this by setting the LD_PRELOAD to point to the
+ library - $ORACLE_HOME/JRE/lib/PA_RISC/native_threads/libjava.sl. The
+ make test passes OK, and make install works. My DBI test script is
+ able to do some basic stuff, so presumably it is OK.
+
+ There are some problems remaining with it, though. You have to
+ set the LD_PRELOAD variable before running any perl against Oracle
+ (as I guess the library does not get built into the DBD). We have
+ also noticed that if you set LD_PRELOAD as above, then run swlist,
+ the system coredumps (swlist works normally without this set).
+
+ This worries me, as it may cause other commands to coredump, so we
+ will need to try to extensively roadtest this before we can move
+ into production.
+
+ The libjava.sl library is only required for an advanced authentication
+ module that we do not use, so we are hoping that we can remove this
+ from our Oracle installation, and get around the problem this way.
+
+ We did manage to install DBD on one of our boxes before Xmas without
+ this problem, so we know that it can be done, we have just lost the
+ recipe that we need. If anyone has any suggestions that we could try,
+ we would be grateful. It is also worth noting that this error was what
+ hung us up trying to get gcc to work, so with this option, we may be
+ able to push forward on this. We will give it a go on another box,
+ and post if we get any joy from this.
+
+ I have included the recipe that we have used below. This does produce
+ a working build, we are just a little concerned about the side effects.
+
+ Cheers,
+
+ Jon
+
+
+ Machine specs:
+
+ HP-UX 11.00
+ Oracle 8.1.6 client
+ HP ANSI C compiler (B.11.02.03)
+
+
+ Downloaded:
+
+ Perl 5.6.1 From http://www.cpan.org/src/index.html
+ <http://www.cpan.org/src/index.html> (Stable release)
+
+ DBI 1.21 From http://search.cpan.org/search?dist=DBI
+ <http://search.cpan.org/search?dist=DBI>
+ DBD:Oracle 1.12 From http://search.cpan.org/search?module=DBD::Oracle
+ <http://search.cpan.org/search?module=DBD::Oracle>
+
+ Create /tmp/perl temporary area and extract tar files
+
+ cd /tmp/perl/perl-5.6.1
+ ../Configure -Ubincompat5005
+ #Prepend additional libraries with "-lcl -lpthread"
+ #Prepend cc flags with "+z"
+
+ make
+ make test
+ make install
+
+ Install DBI
+
+ cd /tmp/perl/DBI-1.21
+ perl Makefile.PL
+ make
+ make test
+ make install
+
+
+ Install DBD:Oracle
+
+ #Set the Oracle environment
+ export ORACLE_HOME=/oracle/app/oracle/product/8.1.6
+ export SHLIB_PATH=/usr/lib:/oracle/app/oracle/product/8.1.6/lib
+ export ORACLE_SID=sid
+ export ORACLE_USERID=userid/password@sid
+ export LD_LIBRARY_PATH=/oracle/app/oracle/product/8.1.6/lib
+
+ export LD_PRELOAD=/oracle/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl
+ # Need to prevent libjava.sl TLS error - need to do this for runtime as well
+
+ cd /tmp/perl/DBD-Oracle-1.12
+ perl Makefile.PL
+
+ cat Makefile | sed 's/PERL_DL_NONLAZY=1/PERL_DL_NONLAZY=0/g' > Makefile.tmp
+ # Need to force load of all libraries
+ mv Makefile.tmp Makefile
+ make
+ make test
+ make install
+
+ Apparently Oracle stored the 64 bit libraries in .../lib & .../rdbms/lib.
+ 32 bit libraries are available in .../lib32 and .../rdbms/lib32. I'm forced
+ to stay with Perl 32bit & the workaround is to manually edit the resulting
+ Makefile. Anyone have a patch to detect & correct this situation?
+
+ John Schaefer
+
+ BAESystems, San Diego
+
+=cut
Added: dbd-oracle/branches/pythian/README.java.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.java.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,322 @@
+README.java
+
+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
+
Added: dbd-oracle/branches/pythian/README.linux.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.linux.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,65 @@
+From: William Fishburne <william.fishburne@verizon.net>
+Date: Tue, 20 May 2003 09:22:30 -0400
+
+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.
+
+
+
+From: Brent LaVelle <brentlavelle@yahoo.com>
+Date: Tue, 2 Sep 2003 11:07:47 -0700 (PDT)
+Message-ID: <20030902180747.69838.qmail@web14310.mail.yahoo.com>
+Subject: RE: Oracle 9i Lite and DBD::Oracle problems [solved]
+
+With the help of Brian Haas and Ian Harisay I got DBD::Oracle working.
+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.
+
+I don't know if Oracle is bulletproof on Linux but the install process
+has some problems.
+
+
+From: John Scoles <scoles@pythian.com>
+Date: Fri, 29 Sep 2005 10:48:47 -0700 (EST)
+Subject: RE: 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 the ""instantclient" directory.
+
+"instantclient" as follows
Added: dbd-oracle/branches/pythian/README.login.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.login.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,7 @@
+This information is now in the DBD::Oracle module pod documentation.
+Use the 'perldoc DBD::Oracle' command to read it.
+
+Note: The test scripts use the ORACLE_USERID environment variable
+to determine who to login as. It's common to use the Oracle demo user
+'scott' with the standard password 'tiger', thus ORACLE_USERID can be
+set to 'scott/tiger', or set it to your own username and password.
Added: dbd-oracle/branches/pythian/README.longs.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.longs.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,81 @@
+Some examples related to the use of LONG types.
+
+For complete working code, take a look at the t/long.t file.
+
+----------------------------------------------------------------------
+
+You must fetch the row before you can fetch the longs associated with
+that row. In other words, use the following alorithm...
+
+ 1) login
+ 2) prepare( select ... )
+ 3) execute
+ 4) while rows to fetch do
+ 5) fetch row
+ 6) repeat
+ 7) fetch chunk of long
+ 8) until have all of it
+ 9) done
+
+If your select selects more than one row the need for step 4 may
+become a bit clearer... the blob_read always applies to the row
+that was last fetched.
+
+Thanks to Jurgen Botz <jbotz@reference.com>
+
+----------------------------------------------------------------------
+Example for reading LONG fields via blob_read:
+
+ $dbh->{RaiseError} = 1;
+ $dbh->{LongTruncOk} = 1; # truncation on initial fetch is ok
+ $sth = $dbh->prepare("SELECT key, long_field FROM table_name");
+ $sth->execute;
+ while ( ($key) = $sth->fetchrow_array) {
+ my $offset = 0;
+ my $lump = 4096; # use benchmarks to get best value for you
+ my @frags;
+ while (1) {
+ my $frag = $sth->blob_read(1, $offset, $lump);
+ last unless defined $frag;
+ my $len = length $frag;
+ last unless $len;
+ push @frags, $frag;
+ $offset += $len;
+ }
+ my $blob = join "", @frags;
+ print "$key: $blob\n";
+ }
+
+With thanks to james.taylor@srs.gov and desilva@ind70.industry.net.
+
+----------------------------------------------------------------------
+
+Example for inserting LONGS From: Andrew Berry <adb@bha.oz.au>
+
+# Assuming the existence of @row and an associative array (%clauses) containing the
+# column names and placeholders, and an array @types containing column types ...
+
+ $ih = $db->prepare("INSERT INTO $table ($clauses{names})
+ VALUES ($clauses{places})")
+ || die "prepare insert into $table: " . $db->errstr;
+
+ $attrib{'ora_type'} = $longrawtype; # $longrawtype == 24
+
+ ##-- bind the parameter for each of the columns
+ for ($i = 0; $i < @types; $i++) {
+
+ ##-- long raw values must have their type attribute explicitly specified
+ if ($types[$i] == $longrawtype) {
+ $ih->bind_param($i+1, $row[$i], \%attrib)
+ || die "binding placeholder for LONG RAW " . $db->errstr;
+ }
+ ##-- other values work OK with the default attributes
+ else {
+ $ih->bind_param($i+1, $row[$i])
+ || die "binding placeholder" . $db->errstr;
+ }
+ }
+
+ $ih->execute || die "execute INSERT into $table: " . $db->errstr;
+
+----------------------------------------------------------------------
Added: dbd-oracle/branches/pythian/README.macosx.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.macosx.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,428 @@
+These instructions allow for the compilation and successful testing of
+DBD::Oracle on MacOS X 10.2.4 and higher, using Oracle 9iR2 DR
+(Release 9.2.0.1.0) or the 10g Instant Client release (10.1.0.3 at the
+time of writing).
+
+MacOS X DBD::Oracle has been tested (and used) under Jaguar (10.2.x)
+and Panther (10.3.x). Jaguar comes with a Perl version of 5.6.0.,
+which I can report to work with DBD::Oracle 1.14 and higher once you
+take certain steps (see below). You may want to install a later perl,
+e.g., Perl 5.8.x. Please refer to:
+
+ Installing Perl 5.8 on Jaguar
+ http://developer.apple.com/internet/macosx/perl.html
+
+for Perl 5.8.0 installation instructions.
+
+DBD::Oracle is likely to not install out of the box on MacOS X
+10.2. nor on 10.3. Manual but different changes will most likely be
+required on both versions.
+
+The key problem on 10.2. (Jaguar) is a symbol clash (caused by a
+function poll() named identically) between the IO library in at least
+Perl 5.6.0 (which is the version that comes with 10.2) and the Oracle
+client library in 9iR2 developer's release for MacOS X. The symptom is
+that your build appears to compile fine but then fails in the link
+stage. If you are running a (possibly self-installed) version of Perl
+other than 5.6.0, there's a chance that you are not affected by the
+symbol clash. So, try to build first without any special measures, and
+only resort to the instructions below if your build fails in the link
+stage with a duplicate symbol error. Note: if it fails to even
+compile, solve that problem first since it is not due to the symbol
+clash.
+
+The key problem on 10.3 (Panther) is that the default perl that comes
+with the system is compiled with multi-threading turned on, which at
+least with the 9iR2 developer's release exposes a memory leak. Your
+DBD::Oracle build will compile, test, and install fine, but if you
+execute the same prepared statement multiple times, the process will
+quickly run up hundreds of megabytes of RAM, and depending on how much
+memory you have it will die sooner or later.
+
+Oracle recently released an "Instant Client" for MacOSX 10.3
+(Panther), which as far as I can attest has none of the problems
+above. Since it is also a very compact download (actually, a series of
+downloads) I highly recommend you install and use the Instant Client
+if you are on 10.3 (Panther) and you do not intend to run the Oracle
+database server on your MacOSX box. See below (Instructions for
+10.3.x) for details.
+
+======================================================================
+Instructions for 10.2.x (Jaguar)
+
+1) Install Oracle exactly per Oracle documentation. If you change
+install locations, then you'll need to modify paths accordingly.
+
+2) There are two ways to remedy the symbol clash. Either edit the
+symbol table of the Oracle client library
+$ORACLE_HOME/lib/libclntsh.dylib.9.0 such that the symbol _poll is no
+longer exported. Alternatively, download, patch, and re-install the
+perl IO modules. I could not successfully repeat the report for the
+former, but I did succeed by doing the latter. Instructions for both
+follow nonetheless.
+
+ 2a) SKIP IF YOU WANT TO OR HAVE SUCCESSFULLY TRIED 2b). Make a
+ backup copy of the $ORACLE_HOME/lib/libclntsh.dylib.9.0 file, or
+ the file this name points to, since we're about to modify that
+ library. Note that the ".9.0" suffix of the file name is version
+ dependent, and that you want to work with the file pointed to
+ through one or a series of symbolic links rather than any of the
+ symbolic links (e.g., one will be called libclntsh.dylib).
+
+ As user 'oracle' execute the following command to fix namespace
+ collisions in Oracle's dynamic libraries.
+
+ nmedit -R ./hints/macos_lib.syms $ORACLE_HOME/lib/libclntsh.dylib.9.0
+
+ *** Recall the above caveats regarding the file name.
+
+ The problem with this is that the version of nm that comes with
+ Jaguar doesn't support the -R flag. I'd be grateful to anyone who
+ can suggest how to edit the symbol table of libraries on MacOS X.
+
+ 2b) SKIP IF YOU WANT TO OR HAVE SUCCESSFULLY TRIED 2a). In this
+ variant, we will patch the Perl IO modules to change the name of
+ the poll() function, as that is where it is defined. In this case,
+ we do not need to do anything with the Oracle libraries. Follow
+ these steps:
+
+ - Download the module IO (IO.pm) from CPAN and unpack it. Check
+ the documentation as to whether the version is compatible with
+ your version of Perl; I used v1.20 with Perl 5.6.0 and had
+ success.
+
+ - The files IO.xs, poll.c, and poll.h need to be patched. Apply
+ the following patches, e.g., by cutting and pasting the marked
+ section into a file perlio.patch and using that file as input
+ for patch:
+
+ $ patch -p0 < perlio.patch
+
+ The patch will basically rename the C implementation of poll()
+ to io_poll(). The other patches were necessary to make v1.20
+ compile with Perl 5.6.0; they may not be necessary with other
+ versions of IO and Perl, respectively.
+
++=+=+=+=+=+=+= Cut after this line
+diff -c ../IO-orig/IO-1.20/IO.xs ./IO.xs
+*** ../IO-orig/IO-1.20/IO.xs Mon Jul 13 23:36:24 1998
+--- ./IO.xs Sat May 10 15:20:02 2003
+***************
+*** 205,211 ****
+ ST(0) = sv_2mortal(newSVpv((char*)&pos, sizeof(Fpos_t)));
+ }
+ else {
+! ST(0) = &sv_undef;
+ errno = EINVAL;
+ }
+
+--- 205,211 ----
+ ST(0) = sv_2mortal(newSVpv((char*)&pos, sizeof(Fpos_t)));
+ }
+ else {
+! ST(0) = &PL_sv_undef;
+ errno = EINVAL;
+ }
+
+***************
+*** 249,255 ****
+ SvREFCNT_dec(gv); /* undo increment in newRV() */
+ }
+ else {
+! ST(0) = &sv_undef;
+ SvREFCNT_dec(gv);
+ }
+
+--- 249,255 ----
+ SvREFCNT_dec(gv); /* undo increment in newRV() */
+ }
+ else {
+! ST(0) = &PL_sv_undef;
+ SvREFCNT_dec(gv);
+ }
+
+***************
+*** 272,278 ****
+ i++;
+ fds[j].revents = 0;
+ }
+! if((ret = poll(fds,nfd,timeout)) >= 0) {
+ for(i=1, j=0 ; j < nfd ; j++) {
+ sv_setiv(ST(i), fds[j].fd); i++;
+ sv_setiv(ST(i), fds[j].revents); i++;
+--- 272,278 ----
+ i++;
+ fds[j].revents = 0;
+ }
+! if((ret = io_poll(fds,nfd,timeout)) >= 0) {
+ for(i=1, j=0 ; j < nfd ; j++) {
+ sv_setiv(ST(i), fds[j].fd); i++;
+ sv_setiv(ST(i), fds[j].revents); i++;
+diff -c ../IO-orig/IO-1.20/poll.c ./poll.c
+*** ../IO-orig/IO-1.20/poll.c Wed Mar 18 21:34:00 1998
+--- ./poll.c Sat May 10 14:28:22 2003
+***************
+*** 35,41 ****
+ # define POLL_EVENTS_MASK (POLL_CAN_READ | POLL_CAN_WRITE | POLL_HAS_EXCP)
+
+ int
+! poll(fds, nfds, timeout)
+ struct pollfd *fds;
+ unsigned long nfds;
+ int timeout;
+--- 35,41 ----
+ # define POLL_EVENTS_MASK (POLL_CAN_READ | POLL_CAN_WRITE | POLL_HAS_EXCP)
+
+ int
+! io_poll(fds, nfds, timeout)
+ struct pollfd *fds;
+ unsigned long nfds;
+ int timeout;
+diff -c ../IO-orig/IO-1.20/poll.h ./poll.h
+*** ../IO-orig/IO-1.20/poll.h Wed Apr 15 20:33:02 1998
+--- ./poll.h Sat May 10 14:29:11 2003
+***************
+*** 44,50 ****
+ #define POLLHUP 0x0010
+ #define POLLNVAL 0x0020
+
+! int poll _((struct pollfd *, unsigned long, int));
+
+ #ifndef HAS_POLL
+ # define HAS_POLL
+--- 44,50 ----
+ #define POLLHUP 0x0010
+ #define POLLNVAL 0x0020
+
+! int io_poll _((struct pollfd *, unsigned long, int));
+
+ #ifndef HAS_POLL
+ # define HAS_POLL
++=+=+=+=+=+=+= Cut to the previous line
+
+ - compile and install as you usually would, making sure that
+ existing but conflicting modules get removed:
+
+ $ perl Makefile.PL
+ $ make
+ $ make test
+ $ make install UNINST=1
+
+ - You are done. Continue with 3).
+
+3) Install the module DBI as per its instructions, if you haven't
+ already done so.
+
+4) Install the DBD::Oracle module.
+
+ $ perl Makefile.PL
+ $ make
+ $ make test
+ $ make install
+
+======================================================================
+Instructions for 10.3.x (Panther)
+
+I highly recommend you install and use the Oracle 10g Instant Client
+for MacOSX 10.3. Compared to traditional Oracle client installations
+it is a very compact download, and it has the memory leak problem
+fixed. As an added benefit, you will be able to seamlessly connect to
+10g databases. Even if you do want to run the database server included
+in the 9iR2 Developer's Release, I'd still use the Instant Client for
+compiling OCI applications or drivers like DBD::Oracle.
+
+If you still decide to use the full 9iR2 DR client, and if all you use
+DBD::Oracle for on MacOSX is development and test scripts that don't
+involve running the same query multiple times or many queries within
+the same perl process, then note that the memory leak will most likely
+never affect you in a serious way. In this case you may not need to
+bother and instead just go ahead, build and install DBD::Oracle
+straightforwardly without any special measures.
+
+That said, here are the details.
+
+0) (If you decided for the 9iR2 DR client, skip to 1.) If you decided
+ to use the 10g Instant Client, make sure you download and install
+ all parts. (Given that this is perl land you may not need the JDBC
+ driver, but why bother sorting out the 25% you may or may not ever
+ need.) Follow the Oracle instructions and copy the contents of each
+ part into the same destination directory. Change to this
+ destination directory and create a symlink lib pointing to '.'
+ (without the quotes):
+
+ $ cd </path/to/my/oracle/instantclient>
+ $ ln -s lib .
+
+ Also, set the environment variable ORACLE_HOME to the path to your
+ instantclient destination directory. Makefile.PL needs it.
+
+ Now return to your DBD::Oracle download. If the version is 1.16 or
+ less you will need to patch Makefile.PL; in later versions this may
+ be fixed already. Apply the following patch, e.g., by cutting and
+ pasting into a file Makefile.PL.patch and then executing
+
+ $ patch -p0 < Makefile.PL.patch
+
+ Here is the patch:
+
++=+=+=+=+=+=+= Cut after this line
+*** Makefile.PL.orig Fri Oct 22 02:07:04 2004
+--- Makefile.PL Fri May 13 14:28:53 2005
+***************
+*** 1252,1257 ****
+--- 1252,1258 ----
+ print "Found $dir/$_\n" if $::opt_d;
+ }, "$OH/rdbms",
+ "$OH/plsql", # oratypes.h sometimes here (eg HPUX 11.23 Itanium Oracle 9.2.0)
++ "$OH/sdk", # Oracle Instant Client default location (10g)
+ );
+ @h_dir = keys %h_dir;
+ print "Found header files in @h_dir.\n" if @h_dir;
+***************
+*** 1286,1292 ****
+--- 1287,1297 ----
+ open FH, ">define.sql" or warn "Can't create define.sql: $!";
+ print FH "DEFINE _SQLPLUS_RELEASE\nQUIT\n";
+ close FH;
++ # we need to temporarily disable login sql scripts
++ my $sqlpath = $ENV{SQLPATH};
++ delete $ENV{SQLPATH};
+ my $sqlplus_release = `$sqlplus_exe -S /nolog \@define.sql 2>&1`;
++ $ENV{SQLPATH} = $sqlpath if $sqlpath;
+ unlink "define.sql";
+ print $sqlplus_release;
+ if ($sqlplus_release =~ /^DEFINE _SQLPLUS_RELEASE = "(\d?\d)(\d\d)(\d\d)(\d\d)(\d\d)"/) {
++=+=+=+=+=+=+= Cut to the previous line
+
+ The first hunk allows Makefile.PL to find the header files which
+ are in a subdirectory sdk, and the second temporarily disables any
+ global and local login.sql scripts which may make the sqlplus call
+ fail. If you don't have a local login.sql script you will most
+ likely be fine without the second hunk.
+
+ Now run Makefile.PL and make sure you provide the -l flag:
+
+ $ perl Makefile.PL -l
+
+ If you receive some ugly error message stating that some *.mk file
+ couldn't be found you forgot to add the -l flag.
+
+ The continue the standard build process by running make. In
+ DBD::Oracle versions 1.16 and earlier this will end in an error due
+ to a failed execution of nmedit -R. Ignore this error. Move on to
+ running the tests, making sure the test scripts can log in to your
+ database (e.g., by setting ORACLE_USERID). Note that by default the
+ Instant Client does not have a network/admin/tnsnames.ora
+ installed. Either install a suitable one, or point TNS_ADMIN to the
+ directory where you keep your tnsnames.ora, or include the full
+ SQLNET connection string in ORACLE_USERID. All three options are
+ documented by Oracle in the README_IC.htm file that comes with the
+ Instant Client, so be sure you read it if you don't understand what
+ I'm writing here.
+
+ All tests should succeed. Complete by make install. You are done!
+ Skip the other steps below, they do NOT apply to the Instant
+ Client. (Although of course you may still install a later version
+ of perl if you have the need.)
+
+1) Until the reason for the memory leak has been found and fixed, you
+ need to remove the condition that exposes it. Apparently, this is
+ multi-threading being enabled in Perl. The Perl 5.8.1RC3 that comes
+ with Panther was compiled with multi-threading enabled, and AFAIK
+ it cannot be turned off at runtime. Note that the problem is
+ independent of whether you run multiple concurrent threads or not.
+
+ Therefore, the solution is to build your own perl. I leave it up to
+ you whether you want to replace the system perl or not. At least
+ Perl 5.8.x comes with instructions as to how to replace the system
+ perl on MacOS X, and what the caveats and risks are. I used 5.8.4,
+ installed in /usr/local, and it worked perfectly fine.
+
+ The key when configuring your custom build of perl is to disable
+ multi-threading (usethreads, useithreads, and usemultiplicity
+ options). More precisely, do not enable them, as they are disabled
+ by default, at least up to version 5.8.5. You can check whether
+ threads are enabled or not by passing -V to ther Perl interpreter:
+
+ $ /path/to/your/perl -V | grep usethreads
+
+ You need to see a line saying, among other things,
+ usethreads=undef. If you see usethreads=define then multi-threading
+ is enabled.
+
+2) If you choose not to replace the system perl, make sure that when
+ you build DBI and DBD::Oracle you provide the full path to your own
+ perl when running Makefile.PL, like so (assuming you installed in
+ /usr/local, which is the default):
+
+ $ /usr/local/bin/perl Makefile.PL
+
+ Also, every time you run a DBD::Oracle script, you must use the
+ full path too, unless your custom-built perl comes before the
+ system perl in the PATH environment. The easiest way to ensure you
+ are using the right perl is to uninstall DBI from the system perl
+ if you did install it under that as well.
+
+3) Continue with 3) as in instructions for Jaguar (making path
+ substitutions for perl as discussed in 2).
+======================================================================
+
+If you have any problems then follow the instructions in the
+README. Please post details of any problems (or changes you needed to
+make) to dbi-users@perl.org and CC them to brooksch@mac.com on MacOSX
+specific problems. Rewrite of part of this readme, Panther
+instructions, and the Perl IO patch is credit to Hilmar Lapp, hlapp at
+gmx.net.
+
+Earlier and original instructions thanks to:
+ Andy Lester <andy@petdance.com>
+ Steve Sapovits <sapovitss@gsicommerce.com>
+ Tom Mornini <tmornini@infomania.com>
+
+
+Date: Tue, 15 Apr 2003 16:02:17 +1000
+Subject: Compilation bug in DBI on OSX with threaded Perl 5.8.0
+From: Danial Pearce <danial@infoxchange.net.au>
+To: <dbi-users@perl.org>
+Message-ID: <BAC1DD89.E5E1%danial@infoxchange.net.au>
+
+In regards to a previous message on this list:
+
+http://archive.develooper.com/dbi-users@perl.org/msg16365.html
+
+I have some more info:
+
+I have compiled and installed Perl just fine with threads enabled:
+
+./Configure -de -Dusethreads -Dprefix=/usr
+make
+make test
+sudo make install
+
+I have then successfully installed Apache and mod_perl as well.
+
+When I try to compile and install DBI, I get a bus error, just like the
+people on this list have previously discussed on the thread above.
+
+If I unpack the DBI, and run perl Makefile.pl, then alter the created
+Makefile so that it uses gcc2 rather than just "cc" then it compiles,
+installs and runs just fine.
+
+The issue here is that Apple have just recently release 10.2.4, which
+updates /usr/bin/{gcc3,gcc2,g++3,g++2} and /usr/bin/cc is a symlink to
+/usr/bin/gcc3, so compilation of DBI under Apple's gcc3 does not work. It
+works find with gcc2 however.
+
+I had the same problem with DBD::Pg, and was able to compile and install
+that using the same fix.
+
+I am unsure if this is a problem with Apple's version of gcc, or a problem
+with the DBI/DBD code itself. Given that all my other open source
+applications are compiling and installing fine, I am thinking there isn't
+anything Apple are going to do about it.
+
+cheers
+Danial
+
+PS: Personal replies please, I have not subscribed to this list.
+
Added: dbd-oracle/branches/pythian/README.sec.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.sec.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,142 @@
+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."
+> :)
+
+------------------------------------------------------------------------------
Added: dbd-oracle/branches/pythian/README.utf8.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.utf8.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,49 @@
+>From Perl 5.6.0 onwards DBD::Oracle supports UTF8 as local
+character set (using OCI8). Thus, when the environment
+variable NLS_LANG ends with "utf8", DBD::Oracle marks Perl
+strings as unicode (when multibyte characters are present).
+This affects the handling of CHAR/VARCHARx columns and
+LONGs/CLOBs.
+
+Multibyte chars in Perl 5.6.0:
+
+Perl 5.6.0 switches to character semantics (as compared to
+byte) for multibyte strings. According to Perl documentation
+this is done transparently to Perl scripts - all builtin
+operators know about it. DBD::Oracle tries to preserve this
+transparency as far as Oracle allows this (see below).
+
+As a consequence, "LongReadLen" now counts characters and
+not bytes when dealing with LONG/CLOB values. Selected LONGs
+and CLOBs will return at most LongReadLen chars, but may
+contain a multiple of that in actual bytes.
+
+blob_read issued on CLOBs will also use character semantics.
+You have to take extra precautions when using such strings
+in a byte-size context, for example a fixed size field in
+a protocol message. This is not specific to DBD::Oracle as
+such, but be warned.
+
+You need patches at least up to 6090 for Perl 5.6.0 for utf8
+to work with DBD::Oracle. (For WinUsers: ActiveState build
+beyond 613 will probably do).
+
+
+Multibyte chars in Oracle 8(i)
+
+CHAR/VARCHAR and friends count size in bytes, not characters.
+If you have a Oracle database created with character set utf8
+and insert a string with 10 characters into a VARCHAR2(10)
+column, this will only work if the string is 10 bytes long.
+If the string is longer, it will fail (and report and error).
+This behaviour is inherent to Oracle/OCI and not influenced
+by DBD::Oracle.
+
+This is then the place where transparency of utf8 breaks. If
+you want to check your parameter lengths before insert, you
+have to switch Perl to bytes semantics (see "use bytes" in
+Perl documentation).
+
+
+
+2000-05-09, Stefan Eissing (se@acm.org)
Added: dbd-oracle/branches/pythian/README.vms.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.vms.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,87 @@
+=head1 README.vms for DBI and DBD::Oracle
+
+Date: Wed, 15 Sep 2004 11:44:09 +0300
+From: Jakob Snoer <jakob.snoer@dk.ibm.com>
+
+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 enviroment 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 functionallity, 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 :)
+
+=cut
Added: dbd-oracle/branches/pythian/README.win32.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.win32.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,222 @@
+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.
+
+If you built Perl with gcc, read README.wingcc as well as this file.
+
+--- other information, some of which is out of date ---
+
+DBD-Oracle for Windows and Oracle Instantclient
+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.06 on a windows 2000 professional OS for use
+with Oracle instantClient ver 10.2.0.1 & 10.1.0.4 requires only a few downloads and
+a minimal number of environment setting. The procedures below were tested on a clean
+Windows 2000 professional 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 (5.8.7 used) from http://www.activeperl.com/.
+
+2) Use the PPM application to get the latest version of DBI
+
+3) Download the Pythian branch of dbd-oracle from http://svn.perl.org/modules/dbd-oracle/branches/pythian
+
+4) Download and unzip the Oracle Instant Client (10.2.0.1 or 10.1.0.4) 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:
+
+5) You will now need the Microsoft Visual C++ toolkit. Which you can get at
+ http://msdn.microsoft.com/visualc/vctoolkit2003/. 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) Enough Downloading and installing go have a coffee.
+
+9) 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
+
+10) On the path where you installed Visual C++ find and edit the vcars32.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;
+
+11) Open a Windows Visual C++ command window from the start menu.
+
+12) Add the path to the instant client directory to the Path command
+ e.g. PATH = C:\Oracle\instantclient;%PATH%
+
+13) Using the "Set" command add "ORACLE_HOME=path to Instant client" to the environment variables.
+ e.g. Set ORACLE_HOME= C:\Oracle\instantclient
+
+14) 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
+
+15) 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 not run correctly is this varaible is not set.
+
+16) 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.
+
+17) From the 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.
+
+18) 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 instep 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.
+
+19) 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
+
+20) You should now be able to run DBD-Oracle on you system
+
+
+
+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 vcars32.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.
+
+10/24/97 -- Jeff Urlwin
+
+Tested with Oracle 8 and OCI 8. Well, not the *new* OCI api, but
+using the same api as always. This version now searches for OCI
+include and library files in $ORACLE_HOME\OCI80, then
+$ORACLE_HOME\OCI73. It will use the first of these found.
+
+In order for the tests to connect successfully, I had to
+set the environment variable ORACLE_USERID to
+scott/tiger@mydb (where mydb is the tns name of your server)
+
+4/8/97 -- Jeff Urlwin
+
+Even though the Oracle libraries under Win32 (NT) do not require the
+environment variable ORACLE_HOME be set for proper operation, the
+Makefile.PL does. Please set the ORACLE_HOME variable to your oracle
+home directory. Mine, for example, is H:\ORANT.
+
+The environment variable TWO_TASK is not supported under Windows.
+Instead Oracle uses the settings LOCAL and REMOTE as described in
+the Oracle Networking Documentation, "Oracle Network Products Getting
+Started for Windows Platforms."
+
+This version was created and tested with the 7.3 client libraries (see
+if you have an OCI73 directory). This version of the Oracle clients
+have a convenient organization, including OCI73\INCLUDE, OCI73\LIB,
+etc. It also has a nice samples directory to test with. Older
+versions had the OCI samples under RDMBS72. This version has not been
+tested (and will not currently work) with anything other than the 7.3
+versions.
+
+Questions should be directed towards the dbi-users mailing list. I will
+try to answer them quickly there. Please put something about Win32 or
+95 or NT in the subject, as I get TONS of other email and spend a fair
+amount of time weeding out messages that are not relevant to what I
+do. I may miss something if the subject is not clear.
Added: dbd-oracle/branches/pythian/README.wingcc.txt
==============================================================================
--- (empty file)
+++ dbd-oracle/branches/pythian/README.wingcc.txt Mon Dec 5 05:18:15 2005
@@ -0,0 +1,21 @@
+14-Sep-2002 -- Michael Chase
+
+Makefile.PL should now create liboci.a for you. If it fails, follow the
+directions below.
+
+19-may-1999
+
+added support for mingw32 and cygwin32 environments.
+
+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.
+
-
[svn:dbd-oracle] r2296 - dbd-oracle/branches/pythian
by byterock