If you use Oracle and you use Perl, then you likely have compiled DBD::Oracle before. Typically, this is a simple "install DBD::Oracle" via the CPAN shell and you are good to go. Well, installing DBD::Oracle on 64-bit Solaris 10 on amd64 was more challenge than usual. It took me the better part of two hours to get it right and I figured if I could save someone that time then I'd be a better person -- you all know I'm always trying to be a better person ;-) heh.
So, Oracle just release amd64 Solaris10 capable client libraries with their 10.2.0.1 release -- and if you are embedding perl in an app to leverage DBD::Oracle (I'm leveraging DBD::Oracle to make connections to Oracle from within postgres via pl/perl and dbi-link), then you must have 64-bit native client libraries or you can't link them into your native 64-bit app.
So, I download the 10.2.0.1 instantclient from Oracle's download section and install it into /opt/oracle and test it:
# cd /opt/oracle # mkdir -p network/admin # vi network/admin/tnsnames.ora ( put in the information about your oracle listeners here ) # LD_LIBRARY_PATH=
Next I run perl -MCPAN -eshell and type install DBD::Oracle and it utterly explodes in my face. No adequate ".mk" files. Hmm.. I find one at /opt/oracle/sdk/demo.mk and after much hackery (I'll recap the next two hours) I find that the ".mk" isn't just formatted incorrectly, but it now libocci relies on the C++ runtime (-lCrun -lCstd) and has a few missing library dependencies that should have been lib link dependencies: -lnnz10 -lociicus. I also believe that it compiles down a tad different when using the C++ compiler instead of the C compiler, so I opted for that. And I did it dirty.
Add the line:
OCISHAREDLIBS=-locci -lclntsh $(THREADLIBS) -lnnz10 -lCstd -lCrun -lociicus
to the demo.mk file after the THREADLIBS= line. and run:
# ( cd /opt/oracle ; \ ln -s . lib ; \ ln -s libocci.so.10.1 lnocci.so ; \ ln -s libclntsh.so.10.1 libclntsh.so ) # ORACLE_HOME=/opt/oracle perl Makefile.PL -m /opt/oracle/sdk/demo.mk
This won't get you all the way, but it will get you a Makefile to start hacking on. Why did this take so much work? Trial and error and apparently the order you link the libraries in matters -- if you mix them up, you will get unresolved symbol resolution errors (mangled C++ names that exist in either Crun or Cstd).
This still did not setup the include paths correctly and I was forced to search and replace in the Makefile rdbms/demo with sdk/include. I added -R/opt/oracle to the LDFLAGS and LDDFLAGS. I changed the local compiler link path from /opt/SUNWspro/prod/lib to /opt/SUNWspro/prod/lib/amd64. Later on the hint that C++ was required led me to change CC=cc to CC=CC to ease other issues. This required 3 casting fixes in dbdimp.c from void pointer to const unsigned char pointer -- you'll see them when you try to compile it.
And... make.. make test... presto! Note, you could likely use the C compiler (cc) instead of the C++ compiler, but I don't have much insight into what the C++ compiler does above and beyond plain-old-cc, so I thought it better safe than sorry.
Anyway, now I have a working DBD::Oracle on Solaris 10 (update 1) 64-bit amd64 linked against Oracle's 10.2.0.1 instant client.