Hi all, So, we've had this bug open for a while at (1), and I guess we've hit on a solution, of sorts. The problem is that we're not using the bundled libltdl (we're using the one packaged in Debian) and so rlm_sql isn't loaded with RTLD_GLOBAL, so loading of rlm_sqlippool fails. The only thing that really makes sense to me is to rlm_sqlippool declare that it needs symbols from rlm_sql (a .NEEDED section in the elf header for us), so that it works no matter which way libltdl is set up. This means adding rlm_sql.la on the link line, which I'm concerned is likely to be unportable across platforms. Do any of you have a better idea about how to proceed? Several other, probably worse, options have occured to me, but I won't bore you with all the details just now. There is a new version of libltdl out there that has new functions for loading with RTLD_GLOBAL, but it looks like the upstream default is for all dlopen'ed objects to be loaded without. Thanks all, 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448699 -- -------------------------------------------------------------------------- | Stephen Gran | "What is wanted is not the will to | | steve@lobefin.net | believe, but the will to find out, | | http://www.lobefin.net/~steve | which is the exact opposite." -- | | | Bertrand Russell, _Sceptical_Essays_, | | | 1928 | --------------------------------------------------------------------------
Stephen Gran wrote:
... This means adding rlm_sql.la on the link line, which I'm concerned is likely to be unportable across platforms.
Libtool will take care of any platform portability issues. It may complain (a lot) but it should work.
Do any of you have a better idea about how to proceed? Several other, probably worse, options have occured to me, but I won't bore you with all the details just now.
Linking against rlm_sql.la is probably the best thing.
There is a new version of libltdl out there that has new functions for loading with RTLD_GLOBAL, but it looks like the upstream default is for all dlopen'ed objects to be loaded without.
OK... Alan DeKok.
On Thu, May 08, 2008 at 04:21:41PM +0200, Alan DeKok said:
Stephen Gran wrote:
... This means adding rlm_sql.la on the link line, which I'm concerned is likely to be unportable across platforms.
Libtool will take care of any platform portability issues. It may complain (a lot) but it should work.
Do any of you have a better idea about how to proceed? Several other, probably worse, options have occured to me, but I won't bore you with all the details just now.
Linking against rlm_sql.la is probably the best thing.
That's what I was hoping you would say. Now for the tedious part - the tools (libtool, in particular) really doesn't seem to want to play when the .so you're linking to doesn't begin with lib*. Does anyone have any great ideas for how to make this work? How difficult would it be to change the name of the modules from rlm_* to librlm_* ? Or is there a better way I'm not seeing?
There is a new version of libltdl out there that has new functions for loading with RTLD_GLOBAL, but it looks like the upstream default is for all dlopen'ed objects to be loaded without.
OK...
Sorry - I didn't quite finish that thought. What I meant to say was that for the time being, we're stuck with either broken modules or using a bundled libltdl, neither of which is a great solution. It looks like libtdl upstream will make it possible to load the way we are again with the stock library, but that will mean code changes in freeradius as well. So, given that either waiting or doing some work now means some changes, which seems like a better plan? Thanks, -- -------------------------------------------------------------------------- | Stephen Gran | Porsche: there simply is no substitute. | | steve@lobefin.net | -- Risky Business | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Stephen Gran wrote:
That's what I was hoping you would say. Now for the tedious part - the tools (libtool, in particular) really doesn't seem to want to play when the .so you're linking to doesn't begin with lib*.
Arg...
Does anyone have any great ideas for how to make this work? How difficult would it be to change the name of the modules from rlm_* to librlm_* ? Or is there a better way I'm not seeing?
The problem is that libtool is getting in the way here. The dynamic linker can link to rlm_foo.so if you point to the file directly. The "lib" prefix requirement is there only for the common case. libtool, on the other hand... if you give it "/path/to/rlm/rlm_foo.la", it will often produce a link line saying "-L/path/to/rlm -lfoo", which is wrong. If you instead link to a library as "-lfoo", it will produce a link line of "/usr/lib/libfoo.so". I can't figure out why it does this. It's retarded.
Sorry - I didn't quite finish that thought. What I meant to say was that for the time being, we're stuck with either broken modules or using a bundled libltdl, neither of which is a great solution. It looks like libtdl upstream will make it possible to load the way we are again with the stock library, but that will mean code changes in freeradius as well.
What code changes?
So, given that either waiting or doing some work now means some changes, which seems like a better plan?
I'd rather see it fixed properly. Alan DeKok.
On Fri, May 09, 2008 at 02:56:54PM +0200, Alan DeKok said:
Stephen Gran wrote:
Does anyone have any great ideas for how to make this work? How difficult would it be to change the name of the modules from rlm_* to librlm_* ? Or is there a better way I'm not seeing?
The problem is that libtool is getting in the way here. The dynamic linker can link to rlm_foo.so if you point to the file directly. The "lib" prefix requirement is there only for the common case.
libtool, on the other hand... if you give it "/path/to/rlm/rlm_foo.la", it will often produce a link line saying "-L/path/to/rlm -lfoo", which is wrong. If you instead link to a library as "-lfoo", it will produce a link line of "/usr/lib/libfoo.so".
It does this even though the .la file says the name of the object does not start with lib*, which is just special.
I can't figure out why it does this. It's retarded.
Agreed.
Sorry - I didn't quite finish that thought. What I meant to say was that for the time being, we're stuck with either broken modules or using a bundled libltdl, neither of which is a great solution. It looks like libtdl upstream will make it possible to load the way we are again with the stock library, but that will mean code changes in freeradius as well.
What code changes?
It looks to me like they've preserved the existing API, but added some new wrapper functions to enable loading with RTDL_GLOBAL. If freeradius wants to continue loading symbols with RTDL_GLOBAL, the dlopen routines will have to be changed to use the new functions. If freeradius wants to not use RTDL_GLOBAL (better, IMHO), then we need to fix the build system to support that somehow. I haven't looked at it for a month or so, so I forget some of the details now. If you like, I'll have another look and see what I can come up with.
So, given that either waiting or doing some work now means some changes, which seems like a better plan?
I'd rather see it fixed properly.
Agreed. -- -------------------------------------------------------------------------- | Stephen Gran | Snow and adolescence are the only | | steve@lobefin.net | problems that disappear if you ignore | | http://www.lobefin.net/~steve | them long enough. | --------------------------------------------------------------------------
participants (2)
-
Alan DeKok -
Stephen Gran