Libtool and Support for Shared Libraries (3)

[Дилян Палаузов]

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 at 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dilyan_palauzov.vcf
Type: text/x-vcard
Size: 380 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120531/6fb9d5d6/attachment.vcf