Full_Name: Booker C. Bense Version: current-dev OS: Solaris 2.7 URL: http://www.stanford.edu/~bbense/booker-bense-000515.patch Submission from: (NULL) (171.64.12.91) - I have built and installed cyrus sasl 1.5.20 with sleepycat DB. This requires that any code that uses -lsasl also use -ldb. A small patch to configure.in fixes this in my case. I'm not sure it's generally the right thing to do. The configure.in patch is at http://www.stanford.edu/~bbense/booker-bense-000515.patch - Perhaps the right thing to do is add --with-sasl-libs
At 09:48 PM 5/15/00 GMT, bbense@stanford.edu wrote: >Full_Name: Booker C. Bense >Version: current-dev >OS: Solaris 2.7 >URL: http://www.stanford.edu/~bbense/booker-bense-000515.patch >Submission from: (NULL) (171.64.12.91) > > >- I have built and installed cyrus sasl 1.5.20 with sleepycat DB. This requires >that any code that uses -lsasl also use -ldb. >A small patch to configure.in >fixes this in my case. I'm not sure it's generally the right thing to do. The dependency depends on how you configure Cyrus SASL. Cyrus SASL can use gdbm, ndbm, or BerkeleyDB. >The configure.in patch is at > >http://www.stanford.edu/~bbense/booker-bense-000515.patch > >- Perhaps the right thing to do is add --with-sasl-libs Given that most everything is linked with SASL, LIBS would work just as well. However, the "real" solution is to detect what SASL is wants, make sure it doesn't conflict with what slapd wants, and (if necessary) add the appropriate flags. For example, I just realized my cyrus was using the dbm interface in FreeBSD3 libc (Berkeley DB 1.86+). Luckily, Berkeley DB 2.7.7 dbm interface is remapped onto other symbols. Such things scare me. Of course, SASL could depend upon other libraries... most of which we likely already pull in.
On Mon, May 15, 2000 at 09:48:28PM +0000, bbense@stanford.edu wrote: > Full_Name: Booker C. Bense > Version: current-dev > OS: Solaris 2.7 > URL: http://www.stanford.edu/~bbense/booker-bense-000515.patch > Submission from: (NULL) (171.64.12.91) > > > - I have built and installed cyrus sasl 1.5.20 with sleepycat DB. This requires > that any code that uses -lsasl also use -ldb. A small patch to configure.in > fixes this in my case. I'm not sure it's generally the right thing to do. > The configure.in patch is at This is wrong. You sasl library should be linked against the libraries it needs, not require other programs to handle it. When you build libsasl, add -ldb to it, and it should work fine. Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
On Mon, 15 May 2000, Ben Collins wrote: > On Mon, May 15, 2000 at 09:48:28PM +0000, bbense@stanford.edu wrote: > > Full_Name: Booker C. Bense > > Version: current-dev > > OS: Solaris 2.7 > > URL: http://www.stanford.edu/~bbense/booker-bense-000515.patch > > Submission from: (NULL) (171.64.12.91) > > > > > > - I have built and installed cyrus sasl 1.5.20 with sleepycat DB. This requires > > that any code that uses -lsasl also use -ldb. A small patch to configure.in > > fixes this in my case. I'm not sure it's generally the right thing to do. > > The configure.in patch is at > > This is wrong. You sasl library should be linked against the libraries it > needs, not require other programs to handle it. When you build libsasl, > add -ldb to it, and it should work fine. > - This only works if you have a shared library version of db. I probably should have one, but my current configuration doesn't. - Booker C. Bense
> > This is wrong. You sasl library should be linked against the libraries it > > needs, not require other programs to handle it. When you build libsasl, > > add -ldb to it, and it should work fine. > > > > - This only works if you have a shared library version of db. I > probably should have one, but my current configuration doesn't. If you don't have a shared library version, then the only way to make this work properly is if sasl were to use libtool (I think db2 does). Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
On Mon, 15 May 2000, Ben Collins wrote: > > > This is wrong. You sasl library should be linked against the libraries it > > > needs, not require other programs to handle it. When you build libsasl, > > > add -ldb to it, and it should work fine. > > > > > > > - This only works if you have a shared library version of db. I > > probably should have one, but my current configuration doesn't. > > If you don't have a shared library version, then the only way to make this > work properly is if sasl were to use libtool (I think db2 does). -AFAIK, cyrus-sasl does use libtool. Anyway this is what it spits at me. /bin/sh ../libtool --mode=link gcc -Wall -W -g -O2 -L/usr/local/lib -R/usr/loca l/lib -o libsasl.la -rpath /usr/local/lib -version-info 8:4:1 common.lo sasluti l.lo server.lo client.lo md5.lo dlopen.lo checkpw.lo config.lo db_berkeley.lo -l db -ldl -lpam -lresolv -ldb -lresolv mkdir .libs *** Warning: This library needs some functionality provided by -ldb. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. - It seems to me that the only way this can work is if you have shared libraries. Linking against static libraries with the a common set of symbols is a classic recipe for mystery errors and spending alot of time down debugging ratholes. - Booker C. Bense
> - It seems to me that the only way this can work is if you have > shared libraries. Linking against static libraries with the a common > set of symbols is a classic recipe for mystery errors and spending > alot of time down debugging ratholes. Agreed. You should recompile sasl with --enable-shared. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
changed notes changed state Open to Closed
see discussion, not applied