Libtool and Support for Shared Libraries

[Greg Banks]

On Tue, May 15, 2012, at 11:52 PM, Дилян Палаузов wrote:
> Hello,
> 
> >>>>> Also, I notice that libcom_err.la is 'noinst'.  How do you expect that cyrus executable will be able to find this code at runtime on a platform which has shared libraries but no system com_err library?
> >>>>
> >>>> When the compilation of the internal com_err is requested, the files
> >>>> from libcom_err.la are compiled with -fPIC and statically linked in
> >>>> libimap and libsieve.
> >>>
> >>> Two questions -
> >>>
> >>> 1) is this happening by accident because we're currently adding -fPIC to
> >>> the global CFLAGS via @PERL_CCLDFLAGS@ ?
> >>
> >> According to my understanding, -fPIC is added, so that the compiled .o
> >> files, can be inserted in a shared library and this is independent from
> >> @PERL_CCLDFLAGS at .
> >
> > Ah.  I was under the impression that libtool+automake would build two
> > different .o files, one with -fPIC for shared libraries and one without
> > for static libraries and executables.
> 
> For installable libraries, this is true, because both static and shared 
> libraries are installed.  For noinst_ (convenience) libraries, this is 
> also true (but I do not know why libtool builds .o files twice and I do 
> not know, if the files that are supposed to be built without -fPIC are 
> build in fact with @PERL_CCLDFLAGS@).

I think there are, or used to be :(, platforms on which you could not
mix -fPIC and not-fPIC code arbitrarily.  In particular, you couldn't
build -fPIC code into a fully static executable.  In any case, -fPIC is
marginally less efficient than non-fPIC code on most platforms (except
MIPS where all code is -fPIC).

I think we should stop using @PERL_CCLDFLAGS@ now, as the .so's
generated from the Perl build will be able to use the new shared
libraries.  Probably we will need to disable those Perl modules in
configure.ac if --disable-shared is given though.

-- 
Greg.