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