On Wed, Jun 27, 2012, at 04:36 PM, Dilyan Palauzov wrote:
> as far as I understand, the systemwide libcom_err.a is non PIC, the
> libcyrus_imap and libcyrus_sieve are PIC and it is not portable to
> dymically link non-PIC libcom_err.a with PIC libcyrus_sieve . Yes, but
> how to proceed in this case? Currently, Makefile.am states, that
> libcyrus_imap depends on libcom_err, and when some application links
> with libcyrus_imap, it automatically links with the system wide
> libcom_err.a (implicit linking with shared libraries vs. explicit
> linking when everything is statically built).
The trouble is twofold:
First, there are two paths through configure which are intended to link
against the system com_err library, but one results in passing -lcom_err
to the libcyrus_imap link phase (which works because it finds the system
libcom_err.so) and the other passes /usr/lib/libcom_err.a (which doesn't
work for the reasons you've pointed out). They should both do
Second, if we have any doubts about whether a library is shared or
static we should pass it as -lfoo to the link line for the executable,
not for the Cyrus shared library. Either works in the former case, only
shared library work in the latter.
> Does somebody know if it is portable to link the PIC executable (e.g.
The executable shouldn't be PIC, that's only needed for shared libraries
or things that will eventually be linked into shared libraries.
> with PIC libcyrus_sieve, and with non-PIC libcyrus_imap ?
> 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 ?
Very little. It really only matters for shared libraries which are
going to be dlopen()ed, of which we currently have none