Several problems on Solaris10

[James]

On 29/12/2018 13:49, Pierluigi Frullani wrote:

>  I've just upgraded my old Solaris 10 update 8 to Solaris 10 update 11
> with the latest patches, but after the reboot with the new update I'm
> having  a lot of problems with dovecot.
>
> 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.)

> 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.


> The first error was a relocation error:
> relocation error: file
> /usr/local/dovecot/lib/dovecot/libdovecot-login.so.0: symbol
> EVP_PKEY_get1_EC_KEY: referenced symbol not found
> Just to bypass this phase I have linked the openssl-1.0.1e in
> /usr/local/lib ( libssl and libcrypto ) but then I got a new relocation
> error:
>
> imap: Error: dlopen(/usr/local/dovecot/lib/dovecot/lib20_fts_plugin.so)
> failed: ld.so.1: imap: fatal: relocation error: file
> /usr/local/dovecot/lib/dovecot/lib20_fts_plugin.so: symbol
> http_url_parse: referenced symbol not found
>
> Did someone has some idea on how to bypass those troubles ?

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.


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."

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

3. On configure set the local paths
--prefix=/opt/XXX \
--sysconfdir=/etc/opt/XXX \
--localstatedir=/var/opt/XXX \
--mandir=/opt/XXX/share/man \
--docdir=/opt/XXX/share/doc/dovecot \


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.


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 suggest building the new dovecot and getting it right but if you want 
to diagnose your current installation here are some command hints you 
might find useful.

-- find dovecot:
# find /opt -type f -name dovecot
/opt/XXX/sbin/dovecot

-- is there a package?
# pkginfo | grep dovecot
# pkginfo | nawk '/dovecot/{print $2}' | while read package
do
    pkginfo -l ${package}
done

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

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