I've wanted to get rid of these for a while. It's 2012, so all sane platforms have dlopen(). That means we can get rid of libltdl. Once libltdl is gone, there are few reasons to use libtool any more. It has various incestuous relationships with libtldl, that "help" portability. Those are no longer useful. Libtool also has cross-platform build hacks for systems which probably no longer exists. The new "jlibtool" program handles cross-platform building for all modern systems. If no one objects, I'll switch the default in the master branch to use the new system. I'll also add in a bunch of new make files, so that all of the modules build. Once that seems to be stable for a while, I'll go ahead and delete libltdl, followed by libtool. And there was much rejoicing. Alan DeKok.
On 09/02/2012 04:51 AM, Alan DeKok wrote:
Once that seems to be stable for a while, I'll go ahead and delete libltdl, followed by libtool.
And there was much rejoicing.
And he looked upon and saw that it was good, and so too his minion looked upon it also seeing it was good, they too rejoiced loudly knowing libtool was banished from their land. So ends the reading for today. +1 -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 09/02/2012 09:51 AM, Alan DeKok wrote:
I've wanted to get rid of these for a while.
It's 2012, so all sane platforms have dlopen(). That means we can get rid of libltdl.
Yeah, libtool is vile +1 kill it. One thing to note: if at some point we want to build FR as a native windows app, it will be necessary to move the server core into a DLL. This is because DLLs cannot load symbols in EXEs in Windows. libtool sort of "handles" this for you, so if we kill it we'll need to handle it ourselves. But TBH that shouldn't be hard; the EXE would just be a stub that called the server entry point in the DLL.
Phil Mayers wrote:
Yeah, libtool is vile +1 kill it.
Also the version in the server is very old...
One thing to note: if at some point we want to build FR as a native windows app, it will be necessary to move the server core into a DLL. This is because DLLs cannot load symbols in EXEs in Windows. libtool sort of "handles" this for you, so if we kill it we'll need to handle it ourselves.
Sure. Or in the short term, statically link the server.
But TBH that shouldn't be hard; the EXE would just be a stub that called the server entry point in the DLL.
Yeah. There really needs to be a "libfreeradius-server.a" library. It should have all server-side functions. But not the socket handling code, which can stay in the main exe. There's also a pthread-win32 library, and a dlopen() wrapper for Windows. So portability should be really minimal. Alan DeKok.
participants (3)
-
Alan DeKok -
John Dennis -
Phil Mayers