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