Build system / win32
p.mayers at imperial.ac.uk
Sun Jun 26 10:56:05 CEST 2011
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.
More information about the Freeradius-Devel