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 not a module, it's a helper program) -- Paul "TBBle" Hampson, from an alternate email client - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
