Andrei Koulik wrote:
> Tuesday, March 26, 2002, 4:28:28 PM, you wrote:
> BN> ducati(bn) radius 613$ ls lib/rlm_dbm.*
> BN> lib/rlm_dbm.a lib/rlm_dbm.la*
> BN> ducati(bn) radius 614$
>
> seems a bug, should be corrected by freeradius developers.
> You can bypass it by coping *.so* files from /src/modules/rlm_dbm/.libs
> to lib directory (/usr/local/lib/).
I believe this has something to do with libtool; the shared library
for rlm_dbm is neved buildt, probably because it can't find libgdbm.
I run configure with --width-rlm-dbm-lib-dir=/local/gnu/lib, and it
seems that libtool is invoked correctly:
/home/b/bn/src/freeradius-0.5/libtool --mode=link /local/gnu/bin/gcc -module
-export-dynamic -O -g -I/local/gnu/include -R/local/gnu/lib -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I../../include -DHAVE_NDBM_H
-o rlm_dbm.la -rpath /home/b/bn/radius/lib rlm_dbm.lo -lgdbm -lnsl -lresolv -lsocket
-lrt -lpthread
As you can see, -R/local/gnu/lib is in the command line as one would
expect. However, libtool never seems to search /local/gnu/lib for the
GDBM library. bt is a -f truss of the above command line:
ducati(bn) rlm_dbm 744$ grep libgdbm ../bt
538: lstat64("/lib/libgdbm[.-]*", 0x00056C80) Err#2 ENOENT
540: lstat64("/usr/lib/libgdbm[.-]*", 0x00056C80) Err#2 ENOENT
542: lstat64("/usr/local/lib/libgdbm[.-]*", 0x00056C80) Err#2 ENOENT
ducati(bn) rlm_dbm 745$
Strange; I'll look into libtool tomorrow to see if I have gotten some-
thing wrong.
--
We tend to meet any new situation by reorganising; and a wonderful method
it can be for creating the illusion of progress while producing confusion,
inefficiency and demoralisation. -- Gaius Petronius, 60 AD
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
