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-bug@gnu.... , 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
>