--On Tuesday, May 27, 2003 17:23 -0400 Alan DeKok <[EMAIL PROTECTED]> wrote:
Owen DeLong <[EMAIL PROTECTED]> wrote:Agreed. I didn't do it, but, it is imposed on me by the "package management"...Hi... I'm having trouble figuring out how to get configure to build FreeRadius correctly. I have a situation where openssl, sasl, openldap are all installed, but, configure isn't finding them. They are installed in a structure like:
/usr/local/sasl /include Includes /lib Libraries
Yuck. That's definitely non standard, and a big source of the problem.
scheme used by the people in charge of such things in the environment in
question.
binaries are under /bin, and other directories may be present depending on the package. Anyway, I can't figure out how to tell configure to handle this. In other packages, I've been able to do something like
configure --with-openldap=/usr/local/ldap
and it has worked. However, with FreeRadius, that only seems to allow it to find the include files. It doesn't seem to add the -L flags to the linker.
Do:
$ cd src/modules/rlm_ldap/ $ ./configure --help
And you should get some help text. Did you try that?
Well, I'm having this problem for rlm_ldap, rlm_leap_tls, and a few others. I was trying to solve this problem at the root configure for FreeRadius if at all possible.
This is a somewhat urgent need, so I'm hoping someone can respond quickly with the simple answer to my question. Also, it would be nice if the list archives were searchable by subject somewhere. If I get a good enough response, I'll try to submit applicable diffs for the INSTALL document to help prevent this question from coming up again.
It's a rare situation, and one due to local misconfiguration, in my personal opinion. We've had other posts saying:
I'll agree with that to some extent. However, I should be able to say "This package is available and it's PREFIX is XYZ" somehow to solve this. That works with almost every other package I've built using autoconf's configure.
"But I installed the libraries in /opt/stuff/january/package/version/new/lib, and FreeRADIUS couldn't find them. What's wrong with it?"
The response then, as now, is "don't do that."
Yeah... That's nice. Given a choice, I wouldn't. However, I have to work in an existing environment where I can't dictate policy to the other people who run this stuff. They're managing a few hundred packages across a few thousand machines. Since I don't want to try and replace their entire group with my own opinion of how things should be to build one package, I kind of need to find an alternative.
If all else fails, you can do:OK... That may be what I need. (ugly, but it might be what's needed)
$ CPPFLAGS="-I /weird/stuff" $ CFLAGS="-I /other/weird/stuff" $ LDFLAGS="-L/even/weirder/stuff -llib" $ export CPPFLAGS CFLAGS LDFLAGS $ ./configure
and it will work. 'configure' is designed to do that.
So you have multiple options to get FreeRADIUS working on your system, and none involve patches or changes to FreeRADIUS.
I didn't figure they would. I offered to provide DIFF's to the INSTALL document documenting the applicable solution for other users. I did not mean to suggest that I thought changing FreeRADIUS was necessary (or even desirable). I would suggest, however, that it would be nice if the behavior of --with-PACKAGE=dir were modified to effect both the -I and -L/-R options applicable to configure, it would probably solve the problem in a cleaner way.
Alan DeKok.Thanks!!!
Owen
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
