Build system / win32

[Phil Mayers]

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.