On Tue, May 15, 2012, at 11:24 PM, Дилян Палаузов wrote: > Hello, > > >>> 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.
Yep. > > >>> 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. > > > > 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 preserving. -- Greg.
