Basically we took rlm_detail and extended it. In other words we first try to put the data to our application. If that fails then we fall back on the normal detail processing. The library we call is not thread safe so we "marked" our module accordingly. Since my last post I got it to work by re-ordering the link options. However I just tried to repeat this build on yet another box and it fails again. The dependencies in our library are long but not really unusual. Here is what worked: -lfreeradius-radius -L/usr/local/billmax/lib -Wl,-rpath=/usr/local/billmax/lib -lbillmax -lxml2 -ldecNumber -L/usr/lib/mysql -lmysqlclient -lc On 4/18/2014 5:05 PM, Phil Mayers wrote:
On 18/04/2014 21:23, Bill Schoolfield wrote:
Well this has turned out to be some sort of linkage/compile issue. On the same server, I can build the shared library for our module from either the source tree from our application or the source tree from freeradius. Building from freeradius works. The other way does not...
Best I can tell the same includes and libraries are used. A ldd of both .so files show commonality though our app has many more referenced libraries. I wonder if we've got a namespace collision somewhere.
Anybody got a suggestion for where to look?
Hmm. Short of a long tedious trawl with objdump/ldd you could either guess - look at the libs your module pulls in and guess which is likely troublesome - or look at all the libs on your system and try to find any with >1 ABI version present.
It could still be something like threading/signals/locking/mutex or similar - it really depends on what libs you're pulling in. Can you describe the module and it's top-level architecture/dependencies? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html