On Wed, Jun 27, 2012, at 04:36 PM, Dilyan Palauzov wrote: > Hello, > > 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 -lcom_err. 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. > imapd) 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 -- Greg.
