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.
- "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.
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?
Със здраве Дилян On 30.05.2012 12:26, Jeroen van Meeuwen (Kolab Systems) wrote:
On 2012-05-29 1:25, Greg Banks wrote:On Mon, May 28, 2012, at 09:33 PM, Dilyan Palauzov wrote:>> [...]probably using make install DESTDIR= with >> libtool is either wrong or implemented/handled wrong in Automake/libtool. > > Well, that sucks. Why do not you use ./configure --prefix=$(DESTDIR), so that make install DESTDIR=somewhere is not necessary? To my understanding installing in DESTDIR is used to create packages,So we now generate dozens of warnings when doing a straightforward, entirely normal, and unavoidable step in the packaging process? I don't see how that's acceptable.While of course in my realm of packaging, I could use ./configure, what I actually use is %configure. It expands to a predefined set of standard configure options such as --prefix=/usr, --libdir=/usr/lib64, etc, along with first exporting a bunch of variables. When the make install DESTDIR=/some/where is issued, we point it to the root directory of a buildroot (%{buildroot}) and expect the other ./configure options to kick in so that everything is still finally placed in the correct directories (i.e.%{buildroot}etc/ for --sysconfdir=%{_sysconfdir}, %{buildroot}usr/lib64 for --libdir=%{_libdir}, etc. exec dir, libexec dir, ...) for which, if the prefix were to be set to the buildroot root directory, we would need to add the options for all the other --*dir= configure options as well. Kind regards, Jeroen van Meeuwen
<<attachment: dilyan_palauzov.vcf>>
