Re: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
Alan DeKok wrote: Frank Seesink <[EMAIL PROTECTED]> wrote: Good news: FreeRADIUS BUILDS UNDER CYGWIN!!! With NO modifications! That's nice to hear. Bad news: 'make install' fails. That shouldn't be much of a problem. I've copy/pasted the end of the output at the end of this message. It's weird. But if you're not using rlm_dbm, just delete the module directory, and type "make install" again. ... Alan, Ok, deleted the rlm_dbm module directory and redid 'make install'. Got further, but not done yet. This time got as far as the following, and if I see it right, I will want this, as it's for EAP. Thoughts? Ideally, I'd really like to get FreeRADIUS to install as it does elsewhere without these gyrations. What exactly do the error messages indicate here? Bug in make on Cygwin? And for what it's worth, the rlm_dbm built just fine, with the appropriate .a .la files as you'd expect. So not really sure what the issue was. Anyway, any help would be appreciated. ... -- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- make[11]: Leaving directory `/usr/local/radiusd/src/modules/rlm_eap/types/rlm_ea p_ttls' make[10]: Leaving directory `/usr/local/radiusd/src/modules/rlm_eap/types' make[9]: Leaving directory `/usr/local/radiusd/src/modules/rlm_eap/types' make[8]: Leaving directory `/usr/local/radiusd/src/modules/rlm_eap' /usr/local/radiusd/install-sh -c -m 755 radeapclient/usr/local/bin cp: `radeapclient' and `/usr/local/bin/#inst.3092#' are the same file make[7]: *** [install-types] Error 1 make[7]: Leaving directory `/usr/local/radiusd/src/modules/rlm_eap' make[6]: *** [install] Error 2 make[6]: Leaving directory `/usr/local/radiusd/src/modules/rlm_eap' make[5]: *** [common] Error 1 make[5]: Leaving directory `/usr/local/radiusd/src/modules' make[4]: *** [install] Error 2 make[4]: Leaving directory `/usr/local/radiusd/src/modules' make[3]: *** [common] Error 1 make[3]: Leaving directory `/usr/local/radiusd/src' make[2]: *** [install] Error 2 make[2]: Leaving directory `/usr/local/radiusd/src' make[1]: *** [common] Error 1 make[1]: Leaving directory `/usr/local/radiusd' make: *** [install] Error 2 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
Frank Seesink <[EMAIL PROTECTED]> wrote: > Good news: FreeRADIUS BUILDS UNDER CYGWIN!!! With NO modifications! That's nice to hear. > Bad news: 'make install' fails. That shouldn't be much of a problem. > I've copy/pasted the end of the output at the end of this message. It's weird. But if you're not using rlm_dbm, just delete the module directory, and type "make install" again. > I've tried looking through the root level Makefile to figure out what > 'make install' is doing...ugh. Question: What is $(R) and where is it > defined? It's not. It's used to install into a sub-directory, without touching "/". e.g. $ R=/home/user/foo make install $ cd /home/user/foo $ tar -zcf ../almost-an-rpm.tar.gz * (copy to similar system) $ cd / $ tar -zxf almost-an-rpm.tar.gz > P.S. There does not appear to be any kind of 'make uninstall'. I'm > guessing admins must rip out FreeRADIUS by hand if it comes > down to that? Yup. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
Alan, Bingo! Pulled down latest CVS today (25Mar2004), and it looks like you added the additional $(LCRYPT) already. Started with a clean CVS copy. Now good news/bad news time. Good news: FreeRADIUS BUILDS UNDER CYGWIN!!! With NO modifications! Bad news: 'make install' fails. I've copy/pasted the end of the output at the end of this message. Now, on the good news side again, I found the executables in ./src/main, and from what I can tell, they work. I suspect the real issue will be whether radiusd.exe works properly. Without a proper setup with radiusd.conf file, etc., I could just get it to kick back the usual error about not finding a config file. The real test is when it does a fork(), etc., as that is likely where any issues will appear. I've tried figuring out where to manually copy everything (e.g., ./raddb to /usr/local/etc/raddb, etc.), but it's a bit confusing. I've tried looking through the root level Makefile to figure out what 'make install' is doing...ugh. Question: What is $(R) and where is it defined? I couldn't find a single reference to it outside of the root level Makefile, and it's not defined anywhere that I can tell. Which means it's blank (which is fine in my case, but more curious than anything). As for the rest, I can see that automake/autoconf are what generate most of this, and my last real experience predates this automated stuff. :-/ I really need to get a book on this. Anyway, we're making headway. './configure' and 'make' work without issue, so that's a start. Now to just get the files installed properly, then I can start testing this out. 8-) P.S.There does not appear to be any kind of 'make uninstall'. I'm guessing admins must rip out FreeRADIUS by hand if it comes down to that? END OF 'make install' OUTPUT FOLLOWS: ... Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- make[7]: Entering directory `/usr/local/radiusd/src/modules/rlm_dbm' /usr/local/radiusd/install-sh -c -d -m 755 /usr/local/bin /usr/local/radiusd/install-sh -c -m 755 rlm_dbm_parser /usr/local/bin cp: `rlm_dbm_parser' and `/usr/local/bin/#inst.3648#' are the same file make[7]: *** [rlm_dbm_install] Error 1 make[7]: Leaving directory `/usr/local/radiusd/src/modules/rlm_dbm' make[6]: *** [install] Error 2 make[6]: Leaving directory `/usr/local/radiusd/src/modules/rlm_dbm' make[5]: *** [common] Error 1 make[5]: Leaving directory `/usr/local/radiusd/src/modules' make[4]: *** [install] Error 2 make[4]: Leaving directory `/usr/local/radiusd/src/modules' make[3]: *** [common] Error 1 make[3]: Leaving directory `/usr/local/radiusd/src' make[2]: *** [install] Error 2 make[2]: Leaving directory `/usr/local/radiusd/src' make[1]: *** [common] Error 1 make[1]: Leaving directory `/usr/local/radiusd' make: *** [install] Error 2 Alan DeKok wrote: Frank Seesink <[EMAIL PROTECTED]> wrote: I have downloaded the CVS files and tried building FreeRADIUS under Cygwin, and I'm all the way down to the build step where it attempts to make radiusd.exe (the daemon itself). Unfortunately, it blows up on something quite simple: undefined _crypt reference. Edit src/main/Makefile. Look for the line building "radiusd". There's a $(LCRYPT) there. It's not enough. Add a *second* $(LCRYPT) as the last entry on the build line, after the $(MODULE_LIBS). 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: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
Frank Seesink <[EMAIL PROTECTED]> wrote: > I have downloaded the CVS files and tried building FreeRADIUS under > Cygwin, and I'm all the way down to the build step where it attempts to > make radiusd.exe (the daemon itself). Unfortunately, it blows up on > something quite simple: undefined _crypt reference. Edit src/main/Makefile. Look for the line building "radiusd". There's a $(LCRYPT) there. It's not enough. Add a *second* $(LCRYPT) as the last entry on the build line, after the $(MODULE_LIBS). Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
Alan, I have downloaded the CVS files and tried building FreeRADIUS under Cygwin, and I'm all the way down to the build step where it attempts to make radiusd.exe (the daemon itself). Unfortunately, it blows up on something quite simple: undefined _crypt reference. Now, there's a -crypt flag in the gcc line, libcrypt.a exists in /lib and /usr/lib (they're the same in Cygwin), and all I can guess is that the autoconf generated files are a bit out of date/sync. I've tried modifying Make.inc at the root level to include all possibly necessary info, but still no go. I am currently rerunning configure after having run autoconf to regenerate it, but I'm afraid my experience with automake/autoconf/etc. is limited. I'm an old dinosaur when it comes to Makefiles and my experience is limited to the older, more manual approach I'm afraid. I'm tinkering with code once again, and thes scripts look like quite an improvement for those looking to build on multiple systems, but I just don't have much experience with them yet. I'm so close I can smell it, but just not there yet. If you have any advice on how to make sure the build files (configure, Makefiles, etc.) are as up-to-date as possible, please advise. Note that results of $ cygcheck -c autoconf automake m4 Cygwin Package Information Package VersionStatus autoconf 2.59-1 OK automake 1.7.9-1OK m4 1.4-1 OK This is as up-to-date as it gets in the Cygwin world, so hopefully we're not too far behind. Frank Seesink wrote: Alan, Thanks very much. I'll pull down the files from CVS first chance I get and let you know how things go. Alan DeKok wrote: ... The latest CVS snapshot has had all references to inet_pton() and inet_ntop() removed. Until the server supports IPv6 completely, they're not needed. ... - 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: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
Alan, Thanks very much. I'll pull down the files from CVS first chance I get and let you know how things go. Alan DeKok wrote: ... The latest CVS snapshot has had all references to inet_pton() and inet_ntop() removed. Until the server supports IPv6 completely, they're not needed. ... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
[EMAIL PROTECTED] (Paul Hampson) wrote: > > So the question is, would it be possible to modify the FreeRADIUS > > source to use IPv4 functions like inet_ntoa() instead of inet_ntop() > > when building under Cygwin? The latest CVS snapshot has had all references to inet_pton() and inet_ntop() removed. Until the server supports IPv6 completely, they're not needed. > It certainly _used_ to build, according to the Cygwin instructions > in the documentation. People might also try Microsoft's SFU tools. They require 2 minor changes to the server source, which I'll commit soon. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
Please wrap your lines at 80 characters. Luckily for me, I could make vim rewrap your entire email with one command. Other list-readers may not be so lucky. On Thu, Mar 18, 2004 at 07:37:27PM -0500, Frank Seesink wrote: > I would very much like to tackle the issue of getting FreeRADIUS to > run on Windows (most likely under Cygwin). I did some Googling and > found that there's been some chitchat here and there, but nothing > definitive. So here's my initial input on the subject, aimed towards > the FreeRADIUS developers. > I have been able to follow the standard > > ./configure make > > sequence, only having the build blow up on an undefined _inet_pton > near the end of the build process. The last few lines of output > follow for reference: > __ > dlltool --as=as --dllname cyggdbm-4.dll --def .libs/cyggdbm-4.dll-def --output-l > ib .libs/libimp-cyggdbm-4.a > gcc rlm_ippool_tool.o -o rlm_ippool_tool.exe -lresolv -lpthread .libs/libimp-cy > ggdbm-4.a > rlm_ippool_tool.o(.text+0x26f): In function `addip': > /usr/local/freeradius-0.9.3/src/modules/rlm_ippool/rlm_ippool_tool.c:115: undefi > ned reference to `_inet_pton' > collect2: ld returned 1 exit status > make[6]: *** [rlm_ippool_tool] Error 1 > make[6]: Leaving directory `/usr/local/freeradius-0.9.3/src/modules/rlm_ippool' > make[5]: *** [common] Error 1 > make[5]: Leaving directory `/usr/local/freeradius-0.9.3/src/modules' > make[4]: *** [all] Error 2 > make[4]: Leaving directory `/usr/local/freeradius-0.9.3/src/modules' > make[3]: *** [common] Error 1 > make[3]: Leaving directory `/usr/local/freeradius-0.9.3/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/usr/local/freeradius-0.9.3/src' > make[1]: *** [common] Error 1 > make[1]: Leaving directory `/usr/local/freeradius-0.9.3' > make: *** [all] Error 2 > __ > A quick 'grep' of the FreeRADIUS source shows this function is called > only ONE time in all of the source code, and that call is in the file > ./src/modules/rlm_ippool/rlm_ippool_tool.c > and there are no instances of inet_pton() in the source. > So the question is, would it be possible to modify the FreeRADIUS > source to use IPv4 functions like inet_ntoa() instead of inet_ntop() > when building under Cygwin? I will investigate this when I have time, > but as you guys have been doing this for some time and know the code > like the back of your hand, figured it's likely a quick click/bang for > you to make the necessary adjustments to the above file. Sadly, this is not simple. The set of functions that fufils the requirements of that function call is disjoint between Cygwin and FreeBSD (I think...). You can check the CVS logs for that file to see what I mean as well as the couple of days on the mailing list where the FreeBSD users beat me with sticks over this very issue when I first comitted rlm_ippool_tool. This wasn't an issue since I think the last person to try this didn't have gdbm for cygwin either. I can see above you've got that... > For what it's worth, I found the following link, which might be of > some help (though not really sure, as I don't code at this level near > as much as I'd like): > http://www.kame.net/newsletter/19980604/ I'd love to switch get getaddrinfo, but from memory that's even less widely supported than inet_pton. I wonder if it's time yet to throw my hands in the air, say "To heck with it" and produce our own resolver library to contain/hide all the evil #ifdefs and whatnot for name resolution No. ;-) > I don't know if there are other Cygwin-unsupported functions lurking > in the FreeRADIUS code, but I must say that this build process has > gone much further than it ever did in the past, so I believe it's > quite close. It certainly _used_ to build, according to the Cygwin instructions in the documentation. > For those not familiar with recent changes in Cygwin, one thing that > has helped immensely is the addition of the minires package, which > provides a minimalist BIND resolver set of functions (something SORELY > missing from Cygwin). This has allowed net apps like FreeRADIUS to > build where they would fail much earlier in the past due to a lack of > libresolv, etc. That's excellent news. Now if only it wasn't GPL-encumbered... > If one of the developers is bored and thinks they know how I can > replace the inet_pton() function with something like inet_aton(), I'll > be more than glad to apply the changes and attempt another build. > Otherwise, I'll have to sit and read for awhile to fathom the > intricacies of these functions and how to use one in place of the > other. :-/ The only solution that presents itself to me is an #ifdef to catch Cygwin-based builds, assuming we can fairly trivially replace inet_pton with inet_aton... (If it's really trivial, a Cygwin-specific macro at the top of the file. After all, it's
FOR FREERADIUS DEVELOPERS: Building FreeRADIUS under Cygwin
SHORT VERSION: I have some information for the FreeRADIUS developers regarding building FreeRADIUS v0.9.3 under Cygwin on MS Windows. With your help/input, I hope to get you the necessary patch(es) you need to have FreeRADIUS build cleanly under Cygwin as it does elsewhere. LONG VERSION: Ok, though I've been using FreeRADIUS since v0.81, this is my first post to this list, so a quick "hey" to everyone. Now down to business. :-) Back in April 2003 I had an email exchange with Alan DeKok regarding FreeRADIUS and mod_auth_radius. At the time I was looking for a Windows binary of mod_auth_radius to use with Apache 1.3.x for Windows, and since then have been sidetracked by one project or another. I hope to get back to that issue at some point, but first, FreeRADIUS itself. I would very much like to tackle the issue of getting FreeRADIUS to run on Windows (most likely under Cygwin). I did some Googling and found that there's been some chitchat here and there, but nothing definitive. So here's my initial input on the subject, aimed towards the FreeRADIUS developers. Using the following configuration: * Intel PIII 866 PC w/ 512MB RAM, 20GB HD, etc. (irrelevant really, but just in case you think you need to know) * Windows XP SP1 w/ all Windows Updates * Cygwin v1.5.8-1 with ALL packages installed (just to be sure ;-) ) * FreeRADIUS v0.9.3 I have been able to follow the standard ./configure make sequence, only having the build blow up on an undefined _inet_pton near the end of the build process. The last few lines of output follow for reference: __ dlltool --as=as --dllname cyggdbm-4.dll --def .libs/cyggdbm-4.dll-def --output-l ib .libs/libimp-cyggdbm-4.a gcc rlm_ippool_tool.o -o rlm_ippool_tool.exe -lresolv -lpthread .libs/libimp-cy ggdbm-4.a rlm_ippool_tool.o(.text+0x26f): In function `addip': /usr/local/freeradius-0.9.3/src/modules/rlm_ippool/rlm_ippool_tool.c:115: undefi ned reference to `_inet_pton' collect2: ld returned 1 exit status make[6]: *** [rlm_ippool_tool] Error 1 make[6]: Leaving directory `/usr/local/freeradius-0.9.3/src/modules/rlm_ippool' make[5]: *** [common] Error 1 make[5]: Leaving directory `/usr/local/freeradius-0.9.3/src/modules' make[4]: *** [all] Error 2 make[4]: Leaving directory `/usr/local/freeradius-0.9.3/src/modules' make[3]: *** [common] Error 1 make[3]: Leaving directory `/usr/local/freeradius-0.9.3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/freeradius-0.9.3/src' make[1]: *** [common] Error 1 make[1]: Leaving directory `/usr/local/freeradius-0.9.3' make: *** [all] Error 2 __ This is not a surprise to me. inet_pton() is an IPv6 function, and I've often found network app builds die due to this or similar. Cygwin only supports IPv4 functions like inet_aton()/inet_ntoa() (i.e., no INET6 support yet), and at the moment IPv6 support in Windows OSes is quite limited (only available in beta form as it were for XP Pro and up, and I believe only now being shipped in a commercial grade version in Windows 2003 Server). Talk of adding INET6 support to Cygwin is ongoing, with a site in Japan leading development, but who knows how long that will be. A quick 'grep' of the FreeRADIUS source shows this function is called only ONE time in all of the source code, and that call is in the file ./src/modules/rlm_ippool/rlm_ippool_tool.c and there are no instances of inet_pton() in the source. So the question is, would it be possible to modify the FreeRADIUS source to use IPv4 functions like inet_ntoa() instead of inet_ntop() when building under Cygwin? I will investigate this when I have time, but as you guys have been doing this for some time and know the code like the back of your hand, figured it's likely a quick click/bang for you to make the necessary adjustments to the above file. For what it's worth, I found the following link, which might be of some help (though not really sure, as I don't code at this level near as much as I'd like): http://www.kame.net/newsletter/19980604/ However, as I've been working on getting other open-source projects to build under Cygwin, I'm starting to learn the ins and outs slowly. (My proudest moment thus far was getting the open-source Jabberd 1.4.x source to build cleanly, and my patches are now part of Jabberd 1.4.3. Yeah! Ok ok, nothing major, but it's a start.) I don't know if there are other Cygwin-unsupported functions lurking in the FreeRADIUS code, but I must say that this build process has gone much further than it ever did in the past, so I believe it's quite close. For those not familiar with recent changes in Cygwin, one thing that has helped immensely is the addition of the minires package, which provides a minimalist BIND resolver set of function
