Hello, On 27.06.2012 22:43, Carson Gaspar wrote:
On 6/27/2012 7:36 AM, Dilyan Palauzov wrote:Moreover, does it make any difference, if imapd links with libcyrus_sieve and libcyrus_sieve links with libcom_err, or if imapd links explicitly with both libcyrus_sieve and libcom_err ?What is calling com_err? The objects in libcyrus_sieve or the objects in imapd? If libcyrus_sieve has unresolved symbols against libcom_err, some linkers will require additional options to allow it to link (GNU ld and Solaris ld both default to allowing unresolved symbols when linking shared objects, but I'm not sure about other platforms - see "-z defs").
com_err, or rather the function error_message is called both by the objects in libcyrus_imap (as in imap/message.c) and directly by the objects in programs (imap/sync_client.c).
In general, you _really_ don't want a shared object depending on a static object, although it's possible to make it work by always linking in the static object in the final executable on many (most?) platforms.
Yes, but this is what is going to happen: if somebody requests during ./configure to use the system-wide (static) library, it has to be used, and the only way to do it, is to link the programs with libcom_err.a and not the libcyrus_ libraries.
By the way, why does ./configure offer to link with static or dynamic cyrus-sasl, and by static and dynamic krb? It is nearly the same as with com_err .
Със здраве Дилян
<<attachment: dilyan_palauzov.vcf>>
