Several problems on Solaris10

Pierluigi Frullani pierluigi.frullani at gmail.com
Mon Dec 31 19:28:11 EET 2018


Answer inline.

On Sun, Dec 30, 2018 at 12:59 PM James <list at xdrv.co.uk> wrote:

> On 29/12/2018 13:49, Pierluigi Frullani wrote:
>
> > My version is 2.2.13 ( it was the last one, at the time of the first
> > server setup ).
>
> 2.2.13 is from around May 2014.  It worked but I can't see why you
> wouldn't switch to the latest 2.3.4. (You might be seeing what I can't
> and your question hasn't explained.)
>

That's the date for installation. I was using the courier-imap and switched
to dovecot.
Not changed since then.


> > I have seen that ( it seems ) the new solaris don't honour the
> > LD_LIBRARY_PATH.
>
> I'm sure it does but you shouldn't need it anyway.
>

Believe me, it doesn't :(


> Did you compile this yourself or are you using someone else's package?
> Solaris has no files in /usr/local, you must have added those.
>

Yes I did compile it by myself using the "configure; make " way, with the
following command:
CPPFLAGS="-I/usr/local/clucene/include -I/usr/local/libtextcat/include
-I/usr/local/openssl-1.0.1e/include" LDFLAGS="-L/usr/local/clucene/lib
-L/usr/local/libtextcat/lib -L/usr/local/openssl-1.0.1e/lib" ./configure
--prefix=/usr/local/dovecot --with-ssl=yes --with-stemmer --with-lucene
--with-zlib

( also tried with --without-shared-libs or without it  )

The problem ( as usual ) arise with the openssl libs that solaris ships, as
they are always missing some parts ( basically for the export laws solaris
adhere :) )
If I compile with the internal (open)ssl libs it won't even finish the
compilation :(

1. Do not put your files in /use/local.  You will clash with someone
> else thinking it is the place to put personal stuff.  man filesystem:
> "/opt  Root of a subtree for add-on application packages."
>

 Being that I'm the only one administering this machine I'm sure it would
not  ;)

2. Do not use LD_LIBRARY_PATH in the run time environment.  Instead use
> the runpath in binaries as set during linking.
>

That's the important point, but please read on.



> 4. When linking use -L to point to the libraries.  These need not be in
> the installation location and during build won't be (because you haven't
> installed yet because you are building new libraries).

5. When linking use -R to point to the installed location of the libraries.
>

 That's fine with me, ( and eventually I will try to modify all the
makefiles, but I hoped it would have already been done by configure ( wich
obviously has not :)



> It should work if the paths are set correctly in the binaries.  A
> generic package can use $ORIGIN.
> It's possible libtool is doing its usual trick of making a simple task
> difficult - I take measures to undo its wrong doing and set -L and -R
> between libtool and ld (cc -G).
>

I will try too ( but wouldn't be nice if the configure tool would do that
for us ? )



> -- what is its run path?
> # dump -Lv /opt/XXX/sbin/dovecot | grep RUNPATH
>

Interesting:
 root at puma dump -Lv dovecot | grep RUN
[10]    RUNPATH
 /usr/local/dovecot/lib/dovecot:/usr/local/lib:/usr/ccs/lib:/lib:/usr/lib:/usr/sfw/lib
so it's obviously missing the openssl libraries


> -- can the runtime linker find the libraries?
> # ldd -r /opt/XXX/sbin/dovecot
>
>

Yes, although not the one I want:
root at puma ldd -r imap-login | egrep "ssl|crypto"
        libssl.so.1.0.0 =>       /usr/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>    /usr/lib/libcrypto.so.1.0.0

At the moment I've applied a workaround by creating a fake script that
change the library path on execution:
=========================================================================
root at puma cat imap-login
#!/bin/sh
LD_LIBRARY_PATH=/usr/local/openssl-1.0.1e/lib:$LD_LIBRARY_PATH

export LD_LIBRARY_PATH
exec /usr/local/dovecot/libexec/dovecot/imap-login.orig
=========================================================================
and it's working but is not something I really like.

Would you ( or could ) show me where to replace -R and -L on Makefile(s) to
fix the runpath trouble ?

I've tried the following:
CPPFLAGS="-I/usr/local/clucene/include -I/usr/local/libtextcat/include
-I/usr/local/openssl-1.0.1e/include" LDFLAGS="-L/usr/local/clucene/lib
-L/usr/local/libtextcat/lib -L/usr/local/openssl-1.0.1e/lib
 -R/usr/local/openssl-1.0.1e/lib " ./configure --prefix=/usr/local/dovecot
--with-ssl=yes --with-stemmer --with-lucene --with-zlib
and it seems to work:

root at puma dump -Lv ./src/imap-login/.libs/imap-login | grep RUN
[14]    RUNPATH
 /usr/local/dovecot/lib/dovecot:/usr/local/lib:/usr/local/openssl-1.0.1e/lib:/usr/ccs/lib:/lib:/usr/lib:/usr/sfw/lib

I will try this weekend to install the new binary and see if it has done
the magic.

BTW, thanks in advance for your time

Pigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20181231/23933608/attachment-0001.html>


More information about the dovecot mailing list