Re: another 2.1.0 compile error

2008-09-22 Thread Mike Stroyan
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, [EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-10 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-10 Thread Greg Woods

On Wed, 2008-09-10 at 08:20 +0100, [EMAIL PROTECTED] 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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-10 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Alan DeKok
Greg Woods wrote:
> Hopefully the feedback provided from that was useful.

  Yes.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
On Tue, 2008-09-09 at 22:48 +0100, [EMAIL PROTECTED] 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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
Hi,

> CentOS box for configure and make. Just a bit more of a pain than
> downloading a release tar file.

but thats the point...the stuff you want isnt in a release tar
just yet - a nightly tarball, i guess, would be what you would
prefer for this sort of action?

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
On Tue, 2008-09-09 at 21:56 +0100, [EMAIL PROTECTED] 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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
On Tue, 2008-09-09 at 21:57 +0100, [EMAIL PROTECTED] 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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
Hi,

> 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 :-)

hey! you cant skip *your* turn! ;-)

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
Hi,

> OK, I got this done. It configures and makes on my system (CentOS

congrats! - GIT is far nicer than some of the older methods of
source retrieval. 

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread John Dennis

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 <[EMAIL PROTECTED]>

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: another 2.1.0 compile error

2008-09-09 Thread John Dennis

Greg Woods wrote:

On Tue, 2008-09-09 at 16:53 +0100, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread John Horne
On Tue, 2008-09-09 at 11:24 -0600, Greg Woods wrote:
> On Tue, 2008-09-09 at 16:53 +0100, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]   Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
On Tue, 2008-09-09 at 19:50 +0200, Alan DeKok wrote:

>   Please checkout and build git.freeradius.org.  

OK, I got this done. It configures and makes on my system (CentOS
release 5.2 (Final) -- x86_64) with no problems. Now on to some fun with
dynamic clients.

--Greg


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Marinko Tarlac

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

  


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
On Tue, 2008-09-09 at 18:54 +0100, [EMAIL PROTECTED] 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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Alan DeKok
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Alan DeKok
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


Re: another 2.1.0 compile error

2008-09-09 Thread Greg Woods
On Tue, 2008-09-09 at 16:53 +0100, [EMAIL PROTECTED] 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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Marinko Tarlac

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

  


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Phil Mayers

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.



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: another 2.1.0 compile error

2008-09-09 Thread Alan DeKok
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


Re: another 2.1.0 compile error

2008-09-09 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


another 2.1.0 compile error

2008-09-09 Thread Greg Woods
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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html