On Tue 17 Aug 2010, Dan Lark wrote:
I am desperately trying to get FR compile from the 2.1.9 source tree. In looking through the configure.in file for the rlm_sql_oracle driver from src/modules/rlm_sql/drivers/rlm_sql_oracle, it would appear that it is either looking for the 8i/9i full blown client install, or a 10g/11g full install or a specific version of the InstantClient, 10.1.0.3. (This particular InstantClient release is no longer available, btw.)
So now my questions:
1. What would the best way for me to make the configure script best recognize the release of the client software that I have installed? 2. The configure.in (and therefore the configure script) are hardcoded to a specific release and architecture. In my case, I am trying to do an x86_64 build. Is there a way to make this more generic? 3. I have tried doing some stuff with the configure.in file to make it work properly with my release of the InstantClient, but running autoconf against the modified configure.in file creates a configure script with syntax errors. It would appear that the original configure script is based on autoconf 2.59, whereas the installed version that I have 2.61. Would that make a difference? 4. Based on my observations, re. the InstantClient version information, it would appear that this code is probably stale. Is this currently even being worked on?
Any suggestions?
Hi Dan I am probably the one to blame for the nasty hacks that support InstaClient. As someone who is definately not an Oracle expert, and not particularly an autoconf expert I had a client about 4 or 5 years ago who changed a project mid-stream from PostgreSQL to Oracle. It didn't really seem sane to do a full Oracle install on the front end Linux RADIUS servers (When the Oracle cluster itself was on Solaris boxes), so I got things "working" with InstaClient, commited the patches and probably no-one has looked closely at it since. I unfortunately can't offer you a lot of help (it was quite some time ago and the details are hazy) other than to say that I remember having a lot more trouble rewriting bits of the FreeRADIUS PHP web interface to support Oracle (and adding some custom PL/SQL stored procs) than the actual configure changes. I would suggest having a go at updating/fixing the configure code and see how far you get... It's not that hard :-) You might even end up as the new Oracle maintainer for FreeRADIUS... :-D Cheers -- Peter Nixon http://peternixon.net/