concerning the rpath for the perl shared objects IMAP.so and
managesieve.so, after all I found that MakeMaker uses as linker by
default the value returned by $Config(ld) (visible by running perl -V
under Linker and Libraries), which is sometimes "ld='cc'" and sometimes
If I do not overwrite the default LD-variable (<=> $config(ld)), then it
might be "cc", which could be gcc or not. I have no idea how to pass
linker flags, if the linker is "cc", but not "gcc" (with gcc the
parameters are passed with -Wl,param). So on the one side, I do not
know how to instruct $config(ld)/the linker in a portable way by passing
-rpath parameters to include rpath in the .so file.
On the other side, at least gnu ld, considers the variable LD_RUN_PATH,
when there are no -rpath parameters passed to it and included the value
of LD_RUN_PATH as rpath in the generated shared object. This is how I
understand the documentation of -rpath in gnu ld:
-rpath=DIR ... If `-rpath' is not used when linking an ELF executable,
the contents of the environment variable `LD_RUN_PATH' will be used if
it is defined.
MakeMaker does set LD_RUN_PATH, before invoking the linker. This leads
to including rpath=$(libdir) in perl/imap/IMAP.so and
perl/sieve/managesieve/managesieve.so . At least this is the logic on
my system. If on other systems the rpath is not included in IMAP.so or
managesieve.so, and LD_RUN_PATH in the resulting perl/imap/Makefile is
set up properly, I cannot say where the problem is.
The discussion with RPATH is only about the perl shared objects. The
other executables and shared libraries have correct RPATH.
With DISTDIR I meant DESTDIR.
About the libtool warnings that come when using DESTDIR, they might be
suppressed by passing --no-verbose or --quiet to libtool, however it
might cause other useful warning to disappear and I guess it cannot be
passed to libtool only in install-mode, but has to be in the compile
mode, too (if it is managed by Automake).