On 6/27/2012 7:36 AM, Dilyan Palauzov wrote:
Does somebody know if it is portable to link the PIC executable (e.g. imapd) with PIC libcyrus_sieve, and with non-PIC libcyrus_imap ?
Yes, executables may be linked with PIC and non-PIC objects (otherwise every executable would need to be compiled PIC...)
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 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"). 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.
-- Carson
