On 06/26/2011 08:47 AM, Alan DeKok wrote:
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".
Ah, I was using "master", and wondered where those had come from. Are you building it directly under windows with msys, rather than cross-compiling? I had to do a fair bit of fiddling to get the latter working (although that could be my environment)
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.
Again it could be the fact I'm trying to cross-compile (Windows is so terrible that I don't have the stomach to actually build on it). libtool can certainly generate DLLs even under cross-compilation; I made a fake project with a similar structure (src/main, src/lib, src/modules) and got it to build src/lib as a DLL and src/main as an .exe. But I did that by following an example that used autoconf and automake, which meant I couldn't trivially compare the resulting build rules with what was implemented in FreeRADIUS :o(
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.
So your intention is to remove libtool completely, and instead use rules in Make.inc to build .so/.dll directly? In which case it makes no sense to look at libtool any further, and I'll drop it. FWIW I wrote a quick LoadLibrary/GetProcAddress -> dlopen/dlsym wrapper the other day, and that works fine; let me know if you want the code. One thing I can't remember is, under windows, if a .dll can import symbols from the .exe that loads it. I have a feeling it cannot, which would necessitate making radiusd a tiny stub .exe ;o( Hopefully I'm wrong!
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.
Ok. Do you want someone to look at this, or do you have it in-hand?
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.
Indeed.