Compiling DBD::Oracle

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 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 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=pwd ORACLE_HOME=pwd ./sqlplus 

That works.

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/ 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 file after the THREADLIBS= line. and run:

 # ( cd /opt/oracle ; \        ln -s . lib ; \        ln -s ; \        ln -s ) # ORACLE_HOME=/opt/oracle perl Makefile.PL -m /opt/oracle/sdk/ 

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 instant client.


comments powered by Disqus
Copyright © 2013 - Theo Schlossnagle - Powered by Hexo
- Ported theme GreyShade -