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@. > > > > 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.
