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.