Build system / win32

[Alan DeKok]

Phil Mayers wrote:
> I spent a bit of time this weekend with the mingw32 cross-compiler and
> pthread/openssl cross-compiled libraries, and it does look like this
> might be possible. It will have a limit of 63 sockets because of the way
> select() works on Windows, and it'll need some slight portability
> tweaks, but the basic concept is sound; I've got a version that will
> start up and parse the config file...

  See the existing source code, "master" branch.  There's a lot of
"ifdef WIN32" there already.  It's been building under MingW for over a
year, and getting as far as "radiusd -v".

  Unfortunately, getting it to start up is just the first step.  The
Windows "posix" API is broken, and needs wrappers to make the server
work.  The "git" project has a lot of these already.  Those could be
used and adapted to make FreeRADIUS run on Windows.

http://repo.or.cz/w/git/mingw/4msysgit.git/blob/HEAD:/compat/mingw.c

  I've already ported a number of those.  See src/lib/missing.c

> ...unfortunately that's as far as it'll get, because the build has
> trouble generating the various shared libraries in DLL form, namely
> libfreeradius-radius and libfreeradius-eap, as well as the rlm_xx.
> 
> The main reason seems to be the build system; If you have a fully
> autoconf/automake and libtool-ised source base, the cross-compile seems
> to work this all out for you, but in the case of FreeRADIUS there seem
> to be a mix - autoconf is used, but automake isn't and the libtool stuff
> seems to be hand-crafted to work around the various bugs it's had?

  "automake" is a waste of time.  It does nothing special.  libtool
*should* be capable of building windows libraries.  I don't think
there's any special magic required.

> Before I spend any more time on this - what's the future of the build
> system? I'm only passingly familiar with autotools, but if we want to
> keep it, I'm happy to take a look?

  I've been looking at getting rid of libtool and libltdl.  See commits
in the "master" branch.  It currently does a static build, but doesn't
do .so's, or .dll's.  Still, a non-libtool build will be optional until
such time as it's widely tested.

> If on the other hand the desire is to junk it (and in particular
> libtool) then there's no point spending any time on it, and I'll try a
> different approach (possibly a hand-crafted makefile.mingw32)

  All it should take is some DLL-specific build rules.  Much of that is
already abstracted in the build system.

  And even if the DLLs build, the socket code has to be fixed.  And
after that, making it run as a service, and then using the Windows event
log, etc.

  Alan DeKok.