Libtool and Support for Shared Libraries (3)

[Дилян Палаузов]

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 .

Със здраве
   Дилян


-------------- next part --------------
A non-text attachment was scrubbed...
Name: dilyan_palauzov.vcf
Type: text/x-vcard
Size: 380 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120629/24ba6524/attachment.vcf