Problems with compiling rlm_sql_oracle module
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? -dan ______________________ Dan Lark, RHCE Systems Engineer, Hargray Communications dan.lark@htc.hargray.com Office: 843-706-1819 | Cell: 843-227-2263 7 Arley Way, Suite 200 (2nd Floor) P.O. Box 3380 Bluffton, SC 29910
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.)
Use the v2.1.x branch from http://git.freeradius.org. It has updated configure scripts. Please tell us if they work, or if they don't.
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?
If you don't want to try the v2.1.x branch, just edit the rlm_sql_oracle/Makefile directly. There's nothing magic about it. Alan DeKok.
Since I can get git traffic through my proxy, the git repo does me absolutely no good. Sorry. I did look at the new configure file from the git webview and looks like it would fix my issue. When are you expecting to do a release from the current git repo? Since I am looking at doing customized RPM for deployment within my company, hacking the Makefile is definitely one possibility that I'll look into. I really want off of SBR, but Oracle backending is a need to have kind of thing. UGH! -dan
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/
Okay, having actually RTFM from Github, I was able to d/l the latest. I was able to get it to compile and here's what I found: 1. ORACLE_HOME should only be set if the user is compiling from a full blown Oracle client install, not just the InstantClient. 2. The user will have be cognizant of the architecture for which his compiling, e.g. x86_64 vs. i386. This is true at least on Linux. 3. The version of libnnz is right now set for Oracle 10, libnnz10.so. I had to tweak this to libnnz11.so to get it to work for Oracle 11. With the myriad of ways that Oracle support could be compiled in, you'd think Oracle would come out with an easy way of doing this. I can dream, can't I? Now the big test will be to see how well it works! -dan
Thinking out loud, I wonder if we couldn't do something on the configure.in ala the way the PHP folk do their configuring. I just glanced at their SVN repo on the web and it does present some possibilities... :-) The URL that I look at, was: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/oci8/config.m 4?revision=300753&view=markup Just a thought.... -dan
Dan Lark wrote:
Thinking out loud, I wonder if we couldn't do something on the configure.in ala the way the PHP folk do their configuring. I just glanced at their SVN repo on the web and it does present some possibilities... :-) The URL that I look at, was:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/oci8/config.m 4?revision=300753&view=markup
Sure. Send a patch. Alan DeKok.
participants (3)
-
Alan DeKok -
Dan Lark -
Peter Nixon