Libtool and Support for Shared Libraries (3)

[Greg Banks]

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.