Libtool and Support for Shared Libraries
gnb at fastmail.fm
Tue May 15 17:38:07 EDT 2012
On Tue, May 15, 2012, at 11:24 PM, Дилян Палаузов wrote:
> >>> commit "convert com_err/et/libcom_err.a to a libtool archive"
> >>> You should also fix the 2nd argument to db_panic() in lib/cyrusdb_berkeley.c.
> I think renaming "errno" to "noerr" in lib/cyrus_berkeley.c:db_panic
> resolves the issue with the macros and has no other impacts.
> >>> 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.
> > 2) would it not be better to bundle the libcom_err code into libcyrus.so
> > ?
> This would require imtest/imtest, netnews/remotepurge and notifyd/notify
> to load code for com_err, which they do not use.
I think of the com_err code as being common library code that any of the
Cyrus code should be able to use, like printf(). Under that
interpretation, the fact that imtest et al don't use error_message() is
either carelessness or an accident, rather than a feature that needs
More information about the Cyrus-devel