Libtool and Support for Shared Libraries (3)

[Greg Banks]

On Thu, May 31, 2012, at 06:25 PM, Дилян Палаузов wrote:
> Hello,
> 
> to sum up the issues with Libtool:
> 
> - the perl shared objects IMAP.so and managesieve.so do not contain 
> Library rpath on Greg's computer, but have it on mine.  I have not 
> checked the details, but I think on my computer -rpath comes from the 
> fact, that to build LDFLAGS the file libdb-4.8.la is considered (when I 
> configure with BDB support), the file contains libdir="/usr/lib64" and 
> this leads to "-Wl,-rpath,/usr/lib64" in LDFLAGS.  At the same time, 
> Automake includes automatically "_rpath = -rpath $(libdir)" variables 
> (at least with --enable-sieve for libsieve, and with --enable-server for 
> libimap, unconditionally for libcyrus_min and libcyrus, and when the 
> bundled libcom_err is used, it is also linked with -rpath $(libdir)). 
> However the cyrus-libraries are installed in $(libdir), and not 
> /usr/cyrus/lib, because we want them to be on a standard location, which 
> is considered by the dynamic loader, and are in ldconfig's path.  So 
> what is the problem, when the perl shared objects do not contain -rpath? 
>   I think the other executables shall also not contain it.

So this problem might not affect you, but it will break FastMail
completely.  We build and install *on the same machine* multiple Cyrus
.deb packages built with different --prefix options.  For this to work,
we expect that

 * When built with --prefix=/foo where /foo != /usr, Cyrus will install
 everything under /foo and nothing at all under /usr (this ensures that
 multiple packages don't try to own the same files, so they can be
 removed and installed independently without concern)

 * If an installed executable e.g. /foo/bin/master is run, it knows how
 to find all the runtime resources it needs to find from subdirectories
 of /foo without further intervention (this ensures we don't need to
 futz with environment variables, nor use full pathnames to service
 executable in cyrus.conf) 

I don't think either of these conditions are onerous, and neither affect
normal vendor Cyrus packaging. With the current build system, these
conditions are both true.  You are proposing to break both of them.


> - "make install DISTDIR=" causes warnings from libtool, that state, that 
> the libraries are not installed on the place they are intended to be 
> installed (as configured) and the executables are not going to work (as 
> they will not be able to find the libraries under the DESTDIR= root). 
> This warning gives right information, on the other side Greg says, that 
> the "make install DISTDIR=" is a normal process that shall not lead to 
> warnings.  I asked at libtool-bug at gnu.org , but I if they do not answer, 
> I can't say anything more about this.

These warnings I find annoying but not fatal.  If they're hard to fix I
can filter them out.  I would have thought that there would be some easy
libtool option to avoid them.

> Apart from the suboptimal building of the perl parl, which was 
> suboptimal before, and is even more suboptimal now, I think that are all 
> points with libtool/shared libraries.
> 
> As the shared libraries were not discussed, is somebody against using 
> shared libraries with cyrus-imapd 2.5 / merging the dev/libtool branch?
> 

-- 
Greg.