Re: no SASL backend available out of: gsasl
Niamh Having no further information, it looks to me that you might have a too old version of gsasl... checking for gsasl_check_version in -lgsasl... yes This line says it can find gsasl and its library. checking for GnuSASL version= 0.2.27... no This line says it fails the version check. Do you have GSASL 0.2.27 or later installed? What does config.log say about it? Regards, Eric. On 10/25/13 15:10, Niamh Holding wrote: Hello Tomasz, Friday, October 25, 2013, 1:08:38 PM, you wrote: TS Try: TS ./configure --with-extra-library-path=/usr/local/lib Makes no difference checking for gsasl.h... yes checking for gsasl_check_version in -lgsasl... yes checking for GnuSASL version= 0.2.27... no configure: error: no SASL backend available out of: gsasl ../conftest: error while loading shared libraries: libgsasl.so.7: cannot open shared object file: No such file or directory
Re: no SASL backend available out of: gsasl
Dnia 2013-10-25, pią o godzinie 15:12 +0100, Niamh Holding pisze: EK What does config.log say about it? As the rooot message said- ./conftest: error while loading shared libraries: libgsasl.so.7: cannot open shared object file: No such file or directory How did the test compilation line looked like? i.e. $ grep 'checking for GnuSASL version' -A1 config.log configure:15860: checking for GnuSASL version = 0.2.27 configure:15879: gcc -o conftest -Wall -Wno-pointer-sign -g -g -O2 -funsigned-char conftest.c -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt -ldl 5
Re: no SASL backend available out of: gsasl
Hello Tomasz, Friday, October 25, 2013, 3:48:23 PM, you wrote: TS How did the test compilation line looked like? configure:15716: checking gsasl.h usability configure:15716: checking gsasl.h presence configure:15716: checking for gsasl.h configure:15727: checking for gsasl_check_version in -lgsasl configure:15752: gcc -o conftest -g -O2 -funsigned-char -L/usr/local/lib -L/usr/lib conftest.c -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt -ldl 5 configure:15793: gcc -o conftest -g -O2 -funsigned-char -L/usr/local/lib -L/usr/lib conftest.c -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt -ldl 5 ./conftest: error while loading shared libraries: libgsasl.so.7: cannot open shared object file: No such file or directory -- Best regards, Niamhmailto:ni...@fullbore.co.uk
Re: no SASL backend available out of: gsasl
Hello Eric, Friday, October 25, 2013, 3:56:25 PM, you wrote: EK Is it possible that the library in /usr/local/lib incompatible is with EK your build? EK For instance a 32-bit library on a 64-bit system? It's possible, I installed ftp://ftp.gnu.org/gnu/gsasl/gsasl-1.8.0.tar.gz ftp://ftp.gnu.org/gnu/gsasl/libgsasl-1.8.0.tar.gz On to CentOS 6.4 64 bit. -- Best regards, Niamhmailto:ni...@fullbore.co.uk
Re: no SASL backend available out of: gsasl
Dnia 2013-10-25, pią o godzinie 16:39 +0100, Niamh Holding pisze: configure:15793: gcc -o conftest -g -O2 -funsigned-char -L/usr/local/lib -L/usr/lib conftest.c -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt -ldl 5 ./conftest: error while loading shared libraries: libgsasl.so.7: cannot open shared object file: No such file or directory Is your dynamic linker configured to look for dynamic libraries in /usr/local/lib ? ( /etc/ld.so.conf ) -- Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/
Re: no SASL backend available out of: gsasl
Dnia 2013-10-25, pią o godzinie 18:55 +0100, Niamh Holding pisze:
cat /etc/ld.so.conf
include ld.so.conf.d/*.con
/usr/local/libf
But correcting it made no difference
After editing /etc/ld.so.conf you need to run ldconfig (as root) to
generate /etc/ld.so.cache
--
Tomasz Sterna:(){ :|:};:
Instant Messaging ConsultantOpen Source Developer
http://abadcafe.pl/ http://www.xiaoka.com/portfolio
sm/router: XML parser error
We have a jabberd2 installation with LDAP client authentication, and roster published from active directory ldap. Our jabber service has stopped working a few times in the last few weeks in the middle of the day; clients (pidgin) are disconnected, and can't reconnect (or only partially reconnect, not sure). Up until today, I was able to resolve the problem by restarting the nonfunctional (but running) sm component. This morning, however, I started getting these: router: Thu Oct 24 10:04:41 2013 [notice] [127.0.0.1, port=48998] error: XML parse error (not well-formed (invalid token)) sm: Fri Oct 25 11:45:48 2013 [notice] error from router: XML parse error (junk after document element) That could be related to bad data in AD, but I don't believe any users were changed by anyone but myself, and don't see anything wrong. In the process of trying to figure out if it was a jabber bug or a data error, I ran under valgrind, which detected (I believe) a buffer over/under run in sx_can_read. That was a stripped binary, so no other details. I'm trying to reproduce the problem now on a 2nd server (which also experienced the problem during the failure period), so far without success. Intimate details follow: Until last week, that was running a debian package I created of 2.2.17; that used ubuntu's package as a template, plus a couple changes I made. Since those changes are now either included upstream, or otherwise unnecessary, I installed ubuntu's vanila 2.2.17 from their saucy suite. I believe the sm hangs (or whatever) happened before and after the upgrade. Checking ubuntu's patch, they only patch one C file, which fixes a typo in an error message. I found XML parse errors in earlier log files, but this time in c2s (only). It's possible that's from a misconfigured client. Also, we recently installed two new AD servers, and retired the old one. It's possible that's not all working as intended. Justin
