| byterock@cvs.perl.org 2005-12-05, 9:33 am |
| 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- F58Temqpg2ItZe00032a
0f@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(DESC
RIPTION=(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_newli
nes.
+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/QuestionA...279cd0f
9!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_H
OME/lib #for 32bit HP
+ export LD_LIBRARY_PATH=$ORA
CLE_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_H
OME/lib #for 32bit HP
+ export LD_LIBRARY_PATH=$ORA
CLE_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=6
4" \
+ ./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@HypoVereinsba
nk.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_VERSI
ON)-$(FCCS_VERSION)
+ PERL_ROOT=$(TOP)/pkg
+ PREFIX=$(PERL_ROOT)/$(PERLDIR)
+ #needed for compatibility with ../biuld.mk:
+ VERSION=$(CPAN_VERSI
ON)-$(FCCS_VERSION)
+
+ MQS=MQSeries-1.14
+ DBDORA=DBD-Oracle-1.12
+ DBI=DBI-1.20
+ EXPAT_VER=-1.95.2
+ MQSERVER='PERL_CHANN
EL/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_ROO
T)
+
+ 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=$(ORAC
LE_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=unde
f
+ 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-use...g/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/...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=unde
f
+ 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,+vnocompatwarning
s -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=unde
f
+ 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=6
4 -Ae'
+ ccflags ='-D_HP-UX_SOURCE -I/usr/local/include +z -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=6
4 -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,+vnocompatwarning
s'
+ 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=unde
f
+ 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=6
4 -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<[url]http://www.geocrawler.com/search/?config=183& words=Roger+Foskett[
/url]>
+
+
+=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=$ORA
CLE_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=$ORA
CLE_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.
+--------------------------------------- |