Build system / win32

[Alan DeKok]

Phil Mayers wrote:
> 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)

  mingw.  It's pretty much as simple as pointing the C compiler to
mingw-gcc.

> 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(

  Hmm... it should just be a matter of getting the right options to libtool.

> 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.

  It's still needed for portability.  But if we can get mingw built
without libtool, that's all for the good.

> 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.

  That would help.

> 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(

  You're probably right.  Maybe for 3.0 we need a
"libfreeradius-server".  Ugh.

>>    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?

  I don't have time for that right now.  Please take a look.

  Alan DeKok.