I am running on CentOS 5.2 on an x86_64 architecture. I note a previous report for a similar system here on the list, but this is not the same error. That one was an error compiling radmin, this is an error compiling the server: gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/local/src/freeradius-server-2.1.0/src -DHOSTINFO= \"x86_64-unknown-linux-gnu\" -DRADIUSD_VERSION=\"2.1.0\" -DOPENSSL_NO_KRB5 -c listen.c -fPIC -DPIC -o .libs/listen.o listen.c: In function 'client_listener_find': listen.c:189: warning: assignment discards qualifiers from pointer target type In file included from command.c:26, from listen.c:1046: /local/src/freeradius-server-2.1.0/src/freeradius-devel/modpriv.h:9:18: error: ltdl.h: No such file or directory In file included from command.c:26, from listen.c:1046: /local/src/freeradius-server-2.1.0/src/freeradius-devel/modpriv.h: At top level: /local/src/freeradius-server-2.1.0/src/freeradius-devel/modpriv.h:30: error: expected specifier-qualifier-list before 'lt_dlhandle' gmake[4]: *** [listen.lo] Error 1 gmake[4]: Leaving directory `/local/src/freeradius-server-2.1.0/src/main' gmake[3]: *** [common] Error 2 gmake[3]: Leaving directory `/local/src/freeradius-server-2.1.0/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/local/src/freeradius-server-2.1.0/src' gmake[1]: *** [common] Error 2 gmake[1]: Leaving directory `/local/src/freeradius-server-2.1.0' make: *** [all] Error 2 I realize this isn't a complete enough report to fully debug this, I'm just curious to know if anyone else has seen this one or whether it's something obvious. I also know that the ltdl.h file is actually there in the libltdl subdirectory, so I can probably figure out how to get around this if I have to. --Greg
Hi,
I am running on CentOS 5.2 on an x86_64 architecture. I note a previous report for a similar system here on the list, but this is not the same error. That one was an error compiling radmin, this is an error compiling the server:
gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/local/src/freeradius-server-2.1.0/src -DHOSTINFO= \"x86_64-unknown-linux-gnu\" -DRADIUSD_VERSION=\"2.1.0\" -DOPENSSL_NO_KRB5 -c listen.c -fPIC -DPIC -o .libs/listen.o listen.c: In function 'client_listener_find': listen.c:189: warning: assignment discards qualifiers from pointer target type In file included from command.c:26, from listen.c:1046: /local/src/freeradius-server-2.1.0/src/freeradius-devel/modpriv.h:9:18: error: ltdl.h: No such file or directory ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6
yep, you havent got all the required development packages installed. libtool-ltdl-devel libtool-ltdl alan
On Tue, 2008-09-09 at 16:53 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
yep, you havent got all the required development packages installed.
libtool-ltdl-devel libtool-ltdl
Thanks, that was it. However, I discovered what I think is a bug in yum in the process. I tried "yum list *ltdl*" and this failed to show these packages; otherwise I might have found this myself. Even "yum list libtool*" doesn't show them, I had to actually list libtool-ltdl-devel* to see the devel package. After this I ran into the previously-noted issue compiling radmin. In Makefile.inc, define LIBREADLINE as "-lreadline -lncurses". Another thing I discovered is that I have to remove the i386 versions of several -devel packages, or I get errors about symbols in wrong format when linking. But I now have 2.1.0 compiled so I can work on setting up dynamic clients, which is a feature we really need here since many of our clients are DHCP-configured workstations. Thanks for the help! --Greg
Greg Woods wrote:
After this I ran into the previously-noted issue compiling radmin. In Makefile.inc, define LIBREADLINE as "-lreadline -lncurses".
Which is also fixed in git.freeradius.org.
But I now have 2.1.0 compiled so I can work on setting up dynamic clients, which is a feature we really need here since many of our clients are DHCP-configured workstations.
The dynamic clients code has a bug. This is fixed in git.freeradius.org. Please checkout and build git.freeradius.org. Unless there are major panics, it will be issued as version 2.1.1 this week. Alan DeKok.
On Tue, 2008-09-09 at 19:50 +0200, Alan DeKok wrote:
Please checkout and build git.freeradius.org.
If I get time to do this before 2.1.1 comes out, I'll give it a shot, but there are no git packages for CentOS and I've never used it before, so I'll have to install git on my Fedora 9 workstation (where git packages do exist), learn to use it, check out the code, copy it to the CentOS box, etc. All doable if I can find the time. --Greg
On Tue, 2008-09-09 at 21:57 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
congrats! - GIT is far nicer than some of the older methods of source retrieval.
I've heard that, but I didn't really get far enough to tell. I had to go through the process of figuring out which packages were needed, that they aren't available on CentOS so I had to use a Fedora workstation, get the packages installed, then poke around long enough to figure out that "git clone git://git.freeradius.org/freeradius-server local-dir-name" was what I needed. Then copy the source tree back to the CentOS box for configure and make. Just a bit more of a pain than downloading a release tar file. --Greg
On Tue, 2008-09-09 at 22:48 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
a nightly tarball, i guess, would be what you would prefer for this sort of action?
What I generally prefer is to wait for a stable release. For my own needs, I could well have done that this time too. But in this case, Alan asked me if I would try building the current pre-release. Since some of the things supposedly fixed were compile problems on systems similar to mine, I went ahead and went through the extra effort. Hopefully the feedback provided from that was useful. --Greg
Hi,
asked me if I would try building the current pre-release. Since some of the things supposedly fixed were compile problems on systems similar to mine, I went ahead and went through the extra effort. Hopefully the feedback provided from that was useful.
yes. but, as I mentioned, would you prefer to have a nightly tarball of the files to be able to perform this function rather than having to be familiar with a revision control system which might not be present for your chosen platform? alan
On Wed, 2008-09-10 at 08:20 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
would you prefer to have a nightly tarball of the files to be able to perform this function rather than having to be familiar with a revision control system which might not be present for your chosen platform?
All other things being equal: yes, it would be nice not to have to install an entire revision control system just to fetch the most recent version of the code. But my response to any sentence I hear that starts out with "all other things being equal" is to say that all other things are never equal. The developers already put a lot of time into something that I benefit from, so I would never ask them for this or begrudge them use of their revision control system of choice, given that waiting for the next stable release is always an option. --Greg
Greg Woods wrote:
All other things being equal: yes, it would be nice not to have to install an entire revision control system just to fetch the most recent version of the code.
I've been trying to keep the git repository pushed to github: http://github.com/alandekok/freeradius-server/tree/master They have a "download" link on their page that lets you download a tar file of the most recent source. It can be very useful. Alan DeKok.
On Tue, 2008-09-09 at 11:24 -0600, Greg Woods wrote:
On Tue, 2008-09-09 at 16:53 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
yep, you havent got all the required development packages installed.
libtool-ltdl-devel libtool-ltdl
Thanks, that was it. However, I discovered what I think is a bug in yum in the process. I tried "yum list *ltdl*" and this failed to show these packages; otherwise I might have found this myself. Even "yum list libtool*" doesn't show them, I had to actually list libtool-ltdl-devel* to see the devel package.
Does something a bit more generic like 'yum list *td*' show you a list of installed and available packages? It works for me on CentOS 5.2, 64-bit. The 'list *ltdl*' worked for me on CentOS 52, 32-bit. John. -- --------------------------------------------------------------- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: John.Horne@plymouth.ac.uk Fax: +44 (0)1752 587001
On Tue, 2008-09-09 at 19:43 +0100, John Horne wrote:
Does something a bit more generic like 'yum list *td*' show you a list of installed and available packages? It works for me on CentOS 5.2,
AAAUGH! I got it figured out. I was in the freeradius-server directory when I tried this, so it turns out that "libtool*" and "*tdl*" actually match directory names, so bash wasn't passing the wildcard to yum. Maybe csh wasn't so wrong to always assume an unquoted wildcard meant you were file globbing. Cost me a couple hours of wasted time (not to mention looking like a moron on the list :-) --Greg
Greg Woods wrote:
On Tue, 2008-09-09 at 19:43 +0100, John Horne wrote:
Does something a bit more generic like 'yum list *td*' show you a list of installed and available packages? It works for me on CentOS 5.2,
AAAUGH! I got it figured out. I was in the freeradius-server directory when I tried this, so it turns out that "libtool*" and "*tdl*" actually match directory names, so bash wasn't passing the wildcard to yum. Wildcards passed to commands must always be quoted or escaped otherwise the shell will process it. Yum info is a classic case of needing to do this. Maybe csh wasn't so wrong to always assume an unquoted wildcard meant you were file globbing. Cost me a couple hours of wasted time (not to mention looking like a moron on the list :-) Nah! We've all done things like this more times than we care to admit. Welcome to the club, your turn to bring refreshments next time :-)
-- John Dennis <jdennis@redhat.com>
On Tue, 2008-09-09 at 15:24 -0400, John Dennis wrote:
Wildcards passed to commands must always be quoted or escaped
Well, no, not always any more. If I did something like "cd /root" first, then the yum commands work just fine. It's a bash feature that if the wildcard doesn't actually match anything, then it is passed as an argument verbatim (as opposed to csh, which would have complained "no match" and not done anything). However, you are correct in the sense that quoting it is the only way to guarantee that it will do what I expect every time. I've just gotten lazy since not quoting it works 99% of the time. --Greg
On Tue, Sep 09, 2008 at 03:28:15PM -0600, Greg Woods wrote:
On Tue, 2008-09-09 at 15:24 -0400, John Dennis wrote:
Wildcards passed to commands must always be quoted or escaped
Well, no, not always any more. If I did something like "cd /root" first, then the yum commands work just fine. It's a bash feature that if the wildcard doesn't actually match anything, then it is passed as an argument verbatim (as opposed to csh, which would have complained "no match" and not done anything).
You can get bash to complain about wildcards that _don't_ match a file by adding shopt -s failglob to your .bashrc. Of course, that can leave you surprised later if you are expecting that non-default behavior and start to work with a login that doesn't set it. And setting it could make it harder to use scripts that do expect the default behavior. -- Mike Stroyan, mike.stroyan@hp.com
Greg Woods wrote:
On Tue, 2008-09-09 at 16:53 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
yep, you havent got all the required development packages installed.
libtool-ltdl-devel libtool-ltdl
Thanks, that was it. However, I discovered what I think is a bug in yum in the process. I tried "yum list *ltdl*" and this failed to show these packages; otherwise I might have found this myself. Even "yum list libtool*" doesn't show them, I had to actually list libtool-ltdl-devel* to see the devel package. We maintain rpm spec files that are known to work on Fedora (some RHEL, CentOS) and if you had consulted that spec file you would have seen the libtool-ltdl-devel dependency.
I know the freeradius source tree and source tarball contains rpm spec files and some suse and redhat specific info but I wonder if that is the right place for that information, the distribution in question will have up to date spec files specific to their distributions, I'm not sure upstream is the place to go looking for it. The last time I looked at the redhat directory it was way out of date. I'm inclined to think for those people who wish to build from upstream they are better off using the autotools configure script included in the freeradius source distribution and not use rpm mechanisms unless the srpm comes from the distribution in question. Afterall autotools was meant to solve the "correctly build on a foreign unknown platform" problem, rpm is not the tool for that job. This is one reason I'm dubious upstream is the place to maintain spec files (IMHO it's kinda backwards ;-) Now having said that, I realize there isn't a 2.1.0 rpm spec file in Fedora yet, so you would be right to say "how can I consult it?", but I'm willing to bet the current 2.0.5 spec file would be pretty close to what 2.1.0 needs. It's the Fedora project's job to make sure our spec file and pre-built packages get upgraded to current upstream in a timely fashion (where the definition of timely is open for vigorous discussion, flames, etc. :-) BTW, RHEL, CentOS, etc. are enterprise stable distributions, don't expect them to contain current versions, it's not in their mandate, Fedora is the place to look for current up-to-date versions of packages. -- John Dennis <jdennis@redhat.com>
John Dennis wrote:
I know the freeradius source tree and source tarball contains rpm spec files and some suse and redhat specific info but I wonder if that is the right place for that information, the distribution in question will have up to date spec files specific to their distributions, I'm not sure upstream is the place to go looking for it. The last time I looked at the redhat directory it was way out of date.
I've taken occasional looks at the upstream spec files, and pulled changes in. But the integration should be a little stronger.
This is one reason I'm dubious upstream is the place to maintain spec files (IMHO it's kinda backwards ;-)
Some people want custom installations. Having an "almost OK' spec file distributed with the source is often easier than pulling the spec file from elsewhere.
Now having said that, I realize there isn't a 2.1.0 rpm spec file in Fedora yet, so you would be right to say "how can I consult it?", but I'm willing to bet the current 2.0.5 spec file would be pretty close to what 2.1.0 needs.
Yes. Alan DeKok.
Hello all, I have upgraded to 2.1.0 and I am experiencing reoccurrring segmentation faults. Previous version was 2.0.5 and was stable. Portions of two full debug examples are included below. Please note that I am using a configuration based on the robust-proxy-accounting example site. I changed my configuration slightly between the first and second debug to more closely resemble the example config but the problem still exists. I believe the crash occurs when the accounting server is down and FS attempts to spool the request to a local file or perhaps when it attempts to read the local spool file. If the remote accounting server is up, FS does not crash. Hope this info helps find the bug. Thanks, Jim L. +- entering group accounting {...} expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/X.X.X.X/detail-20080910 [detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/X.X.X.X/detail-20080910 expand: %t -> Wed Sep 10 12:47:20 2008 ++[detail] returns ok expand: /var/log/radius/radacct/imaginenet/detail-%Y%m%d -> /var/log/radius/radacct/imaginenet/detail-20080910 [detail.imaginenet] /var/log/radius/radacct/imaginenet/detail-%Y%m%d expands to /var/log/radius/radacct/imaginenet/detail-20080910 expand: %t -> Wed Sep 10 12:47:20 2008 ++[detail.imaginenet] returns ok } # server ImagineNet_Detail Going to the next request <<< Received proxied response from internal virtual server. Sending Accounting-Response of id 1 to X.X.X.X port 8286 Finished request 5. Segmentation fault +- entering group accounting {...} expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/X.X.X.X/detail-20080910 [detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/X.X.X.X/detail-20080910 expand: %t -> Wed Sep 10 13:14:10 2008 ++[detail] returns ok expand: /var/log/radius/radacct/imaginenet/detail-%Y%m%d -> /var/log/radius/radacct/imaginenet/detail-20080910 [detail.imaginenet] /var/log/radius/radacct/imaginenet/detail-%Y%m%d expands to /var/log/radius/radacct/imaginenet/detail-20080910 expand: %t -> Wed Sep 10 13:14:10 2008 ++[detail.imaginenet] returns ok } # server ImagineNet_Detail Going to the next request <<< Received proxied response from internal virtual server. server ImagineNet { } Sending Accounting-Response of id 136 to X.X.X.X port 1646 Finished request 33. Segmentation fault
Hi, Jim, when this sort of thing happens you have to follow the advanced debugging method as per the freeradius site - http://bugs.freeradius.org/ ie enable-developer and use the gdb wrapper around the exe alan
Alan, I rebuilt with enable-developer and set ulimit -c unlimited. I also set allow_core_dumps = yes in radiusd.conf. I am still getting seg faults but no core dump files are being created. Jim L. ----- Original Message ----- From: <A.L.M.Buxey@lboro.ac.uk> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, September 10, 2008 2:18 PM Subject: Re: Segmentation fault in 2.1.0
Hi,
Jim, when this sort of thing happens you have to follow the advanced debugging method as per the freeradius site - http://bugs.freeradius.org/ ie enable-developer and use the gdb wrapper around the exe
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I ran radiusd via gdb and was able to capture some data. Created bug 593. http://bugs.freeradius.org/show_bug.cgi?id=593 Thanks, Jim L. ----- Original Message ----- From: "Jim L." <jdl@imaginenet.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, September 10, 2008 3:21 PM Subject: Re: Segmentation fault in 2.1.0
Alan,
I rebuilt with enable-developer and set ulimit -c unlimited. I also set allow_core_dumps = yes in radiusd.conf. I am still getting seg faults but no core dump files are being created.
Jim L.
----- Original Message ----- From: <A.L.M.Buxey@lboro.ac.uk> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Wednesday, September 10, 2008 2:18 PM Subject: Re: Segmentation fault in 2.1.0
Hi,
Jim, when this sort of thing happens you have to follow the advanced debugging method as per the freeradius site - http://bugs.freeradius.org/ ie enable-developer and use the gdb wrapper around the exe
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Jim L. wrote:
I rebuilt with enable-developer and set ulimit -c unlimited. I also set allow_core_dumps = yes in radiusd.conf. I am still getting seg faults but no core dump files are being created.
You can run it inside of gdb. Stop the current service, and do: $ gdb --args radiusd -f The '-f' is so that it doesn't detach from gdb. (gdb) run ... (gdb) thread apply all bt full Alan DeKok.
Jim L. wrote:
I believe the crash occurs when the accounting server is down and FS attempts to spool the request to a local file or perhaps when it attempts to read the local spool file. If the remote accounting server is up, FS does not crash.
I've committed the fix to git. It will be in 2.1.1. Alan DeKok.
On Tue, 2008-09-09 at 15:17 -0400, John Dennis wrote:
I'm inclined to think for those people who wish to build from upstream they are better off using the autotools configure script included in the freeradius source distribution and not use rpm mechanisms
Yes, but there are still packages that are part of the system that are needed to build freeradius (or any other application). In this case, since the freeradius packages that come with CentOS (and RHEL) are for a very old version, and I'm doing this because I really want a feature that is available only in the latest version (even Fedora 9 doesn't have it yet), I build from freeradius source. But that doesn't mean I want (or need) to build all the libraries that freeradius uses from source, since the ones that come with the system are perfectly adequate for that. It's just that as soon as you want to build something from source, now you need the -devel packages that might not have been installed at system install time. That's fine, I'm used to installing -devel packages the first time I want to compile something from source. I just ran into two issues: the first one was the thing with the wildcards happening to match directory names in the freeradius source tree, so that "yum" didn't find the packages. So my usual technique of running "yum list libtool*" didn't list the devel packages because the wildcard matched the "libtool" directory. So I couldn't figure out which -devel package I needed. Quoting the wildcard or executing the command in a different directory solves that. The second problem is that there are packages for both i386 and x86_64 that are both available when running on an x86_64, and the freeradius build craps out if it tries to link against the i386 version (invalid symbol format), so I actually had to remove the -devel.i386 packages before the build could happen. While this was on CentOS, I expect the same things could bite somebody using RHEL (or any x86_64 system with yum). --Greg
Hi,
While this was on CentOS, I expect the same things could bite somebody using RHEL (or any x86_64 system with yum).
i'm usually torn between advocating the use of ./configure or the use of eg rpmbuild and the .spec file for CentOS and Fedora folk. if you used the spec and built your own RPM from source then the required RPMs should have been dealt with. alan
Greg Woods wrote:
I am running on CentOS 5.2 on an x86_64 architecture. I note a previous report for a similar system here on the list, but this is not the same error. That one was an error compiling radmin, this is an error compiling the server: ... /local/src/freeradius-server-2.1.0/src/freeradius-devel/modpriv.h:9:18: error: ltdl.h: No such file or directory
Yeah, I caught that on another system, too. It should be fixed in git.freeradius.org. Part of the issue is that the latest version in source control isn't widely tested until it becomes an official release... at which point lots of people run into issues. Alan DeKok.
Alan DeKok wrote:
Greg Woods wrote:
I am running on CentOS 5.2 on an x86_64 architecture. I note a previous report for a similar system here on the list, but this is not the same error. That one was an error compiling radmin, this is an error compiling the server: ... /local/src/freeradius-server-2.1.0/src/freeradius-devel/modpriv.h:9:18: error: ltdl.h: No such file or directory
Yeah, I caught that on another system, too. It should be fixed in git.freeradius.org.
Part of the issue is that the latest version in source control isn't widely tested until it becomes an official release... at which point lots of people run into issues.
I you want to tag and announce -pre I can arrange for it to be built in a bunch of clean buildroots (we maintain such for building our local RPMs) at least for some RedHat/Fedora variants. Or there's "buildbot"; I might be able to scrounge a server or two to run some VMs on, and host them here.
1.1.7 also requires ltdl (CentOS 5.x) Alan DeKok wrote:
Greg Woods wrote:
I am running on CentOS 5.2 on an x86_64 architecture. I note a previous report for a similar system here on the list, but this is not the same error. That one was an error compiling radmin, this is an error compiling the server:
...
/local/src/freeradius-server-2.1.0/src/freeradius-devel/modpriv.h:9:18: error: ltdl.h: No such file or directory
Yeah, I caught that on another system, too. It should be fixed in git.freeradius.org.
Part of the issue is that the latest version in source control isn't widely tested until it becomes an official release... at which point lots of people run into issues.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Marinko Tarlac wrote:
1.1.7 also requires ltdl
The only changes made to 1.1.x from now on will be security related.
i.e. no new features. no build fixes, etc.
I dont think it was a build fix request - more a comment that 1.1.7 needs ltdl on some platforms due to the way that chosen distro operates. - its a helpful note to others who get caught out by this error. generally, its blindingly obvious when you see something like Error - libfoo.h missing you think, hmmm, i dont have an include. what package provides that include? alan
On Tue, 2008-09-09 at 18:54 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
generally, its blindingly obvious when you see something like
Error - libfoo.h missing
you think, hmmm, i dont have an include.
But if libfoo.h actually exists in the source tree (as in the case of ltdl.h), then it's not so blindingly obvious that the problem is a missing -devel package rather than a configuration/compilation issue. --Greg
Hi,
But if libfoo.h actually exists in the source tree (as in the case of ltdl.h), then it's not so blindingly obvious that the problem is a missing -devel package rather than a configuration/compilation issue.
but you chose to use the system stuff in the configure stage rather than the supplied version, yes? alan
On Tue, 2008-09-09 at 21:56 +0100, A.L.M.Buxey@lboro.ac.uk wrote:
but you chose to use the system stuff in the configure stage rather than the supplied version, yes?
Much of the time, by the time I get around to wanting to build freeradius, it's been months since the server was installed, so I don't really know what's installed on it unless I check. I do know that when include files are not found, it might mean a -devel package needs to be installed. I just ran into a couple of unusual problems doing that this time. --Greg
Hi,
Much of the time, by the time I get around to wanting to build freeradius, it's been months since the server was installed, so I don't really know what's installed on it unless I check. I do know that when include files are not found, it might mean a -devel package needs to be installed. I just ran into a couple of unusual problems doing that this time.
- ah, what i meant was ./configure --help (you'll see a couple of 'use our version rather than system version) things. alan
Yes I know... ( Last few weeks I'm trying to build test system for 2.x.x version. I want to test DHCP functions. All systems we have are already in use and I don't have enough "space" to do some testings :) Alan DeKok wrote:
Marinko Tarlac wrote:
1.1.7 also requires ltdl
The only changes made to 1.1.x from now on will be security related.
i.e. no new features. no build fixes, etc.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (9)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Greg Woods -
Jim L. -
John Dennis -
John Horne -
Marinko Tarlac -
Mike Stroyan -
Phil Mayers