Anton Bobrov wrote:
Xu, Qiang (FXSGSC) wrote:
Unfortunately, our printer is an embedded system, and the OS in it is
a simplied Wind River Linux system. There is no "truss" command
available in it. Even the command "env" is not available. So I don't
know how to set this SASL_PATH into the environment.
surely it has something like setenv(3). if so can you try that ?
However, when I use "ldd" to the library, it displays:
====================================
mbc80:/opt/nc/lib <207> ldd libsasl2.so
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/libdl.so.2 (0xb7eed000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7edb000)
libc.so.6 => /lib/libc.so.6 (0xb7dca000)
/lib/ld-linux.so.2 (0x80000000)
====================================
Shouldn't the libraries for plugins also appear in the list?
i dont think any of them are explicitly linked. afaik they get
loaded dynamically by libSASL based on mech name requested. it
is kinda the whole point of having them as plugins really.
Correct. They get loaded dynamically. When you do sasl_client_init()
it will call the getpath callback in the provided sasl_callbacks list.
(NOTE that mozldap does not allow you to pass in or otherwise override
the getpath callback - it should - as well as allow you to
provide/override the other sasl_callbacks). The fallback if there is no
getpath is to look in SASL_PATH or the path built into libsasl2.so when
it was compiled. It will then assume every shared lib in that directory
is a sasl mech plugin and attempt to dynamically load it.
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap