Patch welcome. Version in 1.15 is current and unmodified to the best of
my knowledge. Please don't forget to add yourself to the contributor
list. Thanks.
I'm not doing a lot of HP work these days, so I will probably not be
testing your recipes, but it looks like a reasonably good summary.
Lincoln
On Tue, 2004-03-23 at 10:53, J.D. Laub wrote:
> I've just had success building DBD::Oracle 1.15 on HP-UX 11.11
> (against both oracle 8.1.7 & oracle 9.2.0) & thought I'd share my
> experience.
>
> Disclaimer: these instructions relate to our environment. It may be
> that our sysadmins/dbas chose to configure/install things a certain
> way (i.e., our install of $ORACLE_HOME/bin/sqlplus was *chosen*
> to be 1.1/32), and/or that we're running old versions of software
> (i.e., perhaps later releases of gcc don't ignore -mpa-risc-1-1).
> In fact, there are probably some mistruths in here; rest assured
> they're not intentional. :-)
>
> I'm unsure how (if?) I should go about getting this information into
> the DBD::Oracle README.hpux. Lincoln, please contact me with any
> thoughts you have.
>
>
> ### The summary ################################
>
> Use the ansic compiler (~US$800/cpu).
>
> Shell variables I used:
> PATH=/bin:$PATH # use 32bit ar & nm since using a 32bit cc
> PERLDEST=/opt/perl_ora8 # or "perl_ora9" for an ora9 build
> PATH=$PERLDEST/bin:$PATH # for build of DBI, pick up new perl
> export LDLOADLIBS='+b : +s' # handy for ORACLE_SID connections to ora7
> unset PERLLIB # important to avoid outdated cruft
> export ORACLE_USERID=scott/tiger # insecure - consider using "/"
> ORACLE_SID=orcl
> ORAENV_ASK=NO
> . oraenv # sets LD_LIBRARY_PATH and SHLIB_PATH
>
> For ora8:
> sh ./Configure -d -e -Dprefix=$PERLDEST \
> -A prepend:libswanted='cl pthread ' \
> -A prepend:ccflags='+z +DAportable ' \
> -A prepend:ldflags='+z +DAportable '
>
> For ora9:
> sh ./Configure -d -e -Dprefix=$PERLDEST \
> -A prepend:libswanted='cl pthread ' \
> -A prepend:ccflags='+z +DA2.0W ' \
> -A prepend:ldflags='+z +DA2.0W ' \
> -Dlibpth='/usr/lib/pa20_64 /usr/local/pa20_64/lib'
>
> After you use the above to install perl, DBI & DBD::Oracle will
> build in the normal fashion.
>
>
> ### General Notes ################################
>
> * During "make test", I received 1 failure (on
> lib/ExtUtils/t/Constant) for ora8, and 3 failures (on
> lib/ExtUtils/t/Constant, lib/ExtUtils/t/recurs, and t/op/write) for
> ora9. Nevertheless, things seem mostly OK.
>
> * These are the various combinations possible for a given compiled
> file on HP-UX 11.11 (the quoted description is what gets kicked out
> by the "file" command):
>
> PA-RISC1.1/32bit ("PA-RISC1.1 relocatable object")
> (I'll call this 1.1/32)
> PA-RISC2.0/32bit ("PA-RISC2.0 relocatable object")
> (I'll call this 2.0/32)
> PA-RISC2.0/64bit ("ELF 64-bit MSB relocatable, PA-RISC 2.0 (LP64)")
> (I'll call this 2.0/64)
>
> * "perl -v" lies about the RISC level:
> $ file ./perl
> ./perl: PA-RISC1.1 shared executable dynamically linked -not stripped
> $ ./perl -v | grep RISC
> This is perl, v5.8.3 built for PA-RISC2.0
>
> * If you'll be linking against 2.0/64 libraries, you'll have to
> build all your object modules that way. I've not yet found a way
> to link 32bit executables to 64bit libraries (and vice versa). Run
> the "file" command on your Oracle libraries to find out which path
> you'll have to take.
>
> * Two environment variables control where libraries are
> searched. LD_LIBRARY_PATH and SHLIB_PATH (in that order) are
> used for 64bit executables, while SHLIB_PATH is used for 32bit
> executables.
>
> * I tried attempts using aCC as well as the default (free) cc that
> comes with hpux; both avenues were too problematic to continue
> pursuing.
>
> * The format of compiled objects is specified by compiler options.
> According to the ansic compiler docs, the options are "+DAportable"
> (for 1.1/32), "+DA2.0" (for 2.0/32), and "+DA2.0W" (for 2.0/64).
> For gcc, the corresponding switches are -mpa-risc-1-1 (for 1.1/32)
> and -mpa-risc-2-0 (for 2.0/64), but I've found that -mpa-risc-1-1
> is ineffective. (According to the "file" command, you *always* get
> 2.0/64.)
>
> * Our gcc displays the behavior described at
> http://sources.redhat.com/ml/binutils/2002-10/msg00586.html and
> http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/1641238
> , so is therefore unusable anytime '-lcl' is to be specified.
> Unfortunately, that library is required for DBD::Oracle builds.
> (The workaround of adding the 3 declarations does seem to work,
> but littering those throughout perl's Configure, main.c, etc.
> seems a big task.) Attempts to get gcc to use the hp ld instead
> of the gnu ld (by specifying -mno-gnu-ld and -fno-gnu-linker) were
> unsuccessful. The first html link shown above indicates you have
> to rebuild gcc to use the hp linker, and that was not an incredibly
> desirable path to pursue.
>
> * Our default PATH was set to put /usr/local/pa20_64/bin ahead of
> /bin. This caused problems because (I think) the 64bit versions
> of either ar (the archiver) or nm (the symbol lister) do not play
> well with /bin/cc (the 32bit compiler). The tweak to put /bin at
> the head of PATH, so we get the 32bit versions, takes care of the
> problem.
>
> * I ran into an intermittent quirk during the build of perl in which
> typing "make" (just after the Configure) did nothing. It turns out
> that only dependencies were being written to "makefile", and that
> removing "makefile" (so it could be automatically rebuilt) solved
> the problem.
>
> * Most of my research on finding the right compiler/linker switches
> was done with a "hello world" C program, trying the various
> compilers and options, and trying to link it with the oracle
> libraries. This proved to be a good choice, as trying to test
> compilers/switches against the perl source distribution would have
> proved quite difficult.
>
>
> ### DBD::Oracle specific ################################
>
> * ora8 delivers its libraries in 2 formats: 1.1/32 (under
> $ORACLE_HOME/lib) and 2.0/64 (under $ORACLE_HOME/lib64). ora7
> delivers only 1.1/32, while ora9 delivers only 2.0/64. It may seem
> a bit inconsistent considering the ora8 setup, but ora9 libraries
> are found under $ORACLE_HOME/lib and not $ORACLE_HOME/lib64.
>
> * Under ora8, oraenv incorrectly sets LD_LIBRARY_PATH to include
> $ORACLE_HOME/lib instead of $ORACLE_HOME/lib64, so you've got to
> make an override in oraenv_local if you want to use 2.0/64. It
> doesn't harm anything, but oraenv unnecessarily sets LD_LIBRARY_PATH
> for ora7 (a 64bit environment variable for a 32bit application).
>
> * If you use shared libraries AND you'll be upgrading Oracle, you
> should expect you'll need to rebuild DBD::Oracle unless you'll keep
> the old Oracle libraries available.
>
> * If you're building against ora8, the setting of LDLOADLIBS
> is recommended so that when oraenv set SHLIB_PATH to the
> $ORACLE_HOME/lib for ora7, the code will still find the ora8
> libraries.
>
> * We expect to need local (ORACLE_SID) connections for ora8 &
> ora9. We could have gone with a single 2.0/64 perl coupled with
> 2 DBD::Oracle installs and PERLLIB twiddling in oraenv_local to
> get to the right one. Instead, we chose to do 2 perl installs
> (/opt/perl_ora8 and /opt/perl_ora9) because we can also connect
> locally to ora7 by using the 1.1/32 ora8 version, something that
> isn't possible with a 2.0/64 version. Also, we've some older 1.1/32
> machines into which we'd like to plop a tarball of the perl stuff,
> so a 1.1/32 executable was desirable.
>
> * Some tests I ran were hinting that with 2.0/64, specifying "+b :"
> on the build of DBD::Oracle correctly configured Oracle.sl as far as
> the chatr program is concerned, but it seemed that LD_LIBRARY_PATH
> *always* needed to be set correctly. (I.e., the embedded path in
> the library seemed to be ignored.) I didn't pursue researching this
> since there's no way to get the ora9 compiled code to connect to
> ora8, meaning LD_LIBRARY_PATH had to be set correctly anyway.
>
> Testing local (ORACLE_SID) connections:
> builds against 1.1/32 ora8 can connect to ora7
> builds against 1.1/32 ora8 cannot connect to ora9: "ERROR OCIEnvInit"
> builds against 2.0/64 ora8 cannot connect to ora9: "ERROR OCIEnvInit"
> builds against 2.0/64 ora9 cannot connect to ora8 or ora7: "UNKNOWN
> OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and NLS
> settings etc."
>
> Testing remote (sqlnet) connections:
> builds against 1.1/32 ora8 can connect to ora7
> builds against 1.1/32 ora8 can connect to ora9
> builds against 2.0/64 ora9 can connect to ora8
> builds against 2.0/64 ora9 cannot connect to ora7: "OCI-21500: internal
> error code"
>
>
> ### Versions ################################
>
> perl: 5.8.3
> dbi: 1.41
> dbd-oracle: 1.15
> $ strings /bin/cc | grep Compiler
> HP92453-01 B.11.11.08 HP C Compiler
> $ strings /bin/ld | grep linker
> $Revision: 92453-07 linker linker crt0.o B.11.16 000601 $
> @(#)92453-07 linker command s800.sgs ld PA64 B.11.18 REL 000922
> $ gcc -v
> Reading specs from /usr/local/pa20_64/lib/gcc-lib/hppa64-hp-hpux11.11/3.3.1/specs
> Configured with: ../src/configure --enable-languages=c,c++
> --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as
> --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
> --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
> --host=hppa64-hp-hpux11.11
> Thread model: single
> gcc version 3.3.1
