Dovecot 2.2.25 fails on SSL

[Joseph Tam]

Andreas M. Kirchwitz writes:

>> You can also affect where shared libraries are loaded using the
>> LD_LIBRARY_PATH environment variable.  Try adding
>>
>>  	LD_LIBARY_PATH=/location/of/libdir; export LD_LIBARY_PATH
>>
>> to your service boot scripts.
>
> Thanks for the advice. It's fine for a temporary working around
> problems (like this one, so you're absolutely right :-)
>
> However, no program should require that for regular use because
> you never know exactly if somebody in the chain of executed code
> removes certain environment variables. And also the opposite way,
> if Dovecot runs external programs, those might not play well
> with an existing LD_LIBARY_PATH and incompatible SSL libraries.

Sure,  I understand this, but it's handy in lots of cases where you
need to loading from an alternate location.  Not everyone has access
to resource to recompile.

> For every program I compile myself, I link it against my custom
> OpenSSL library (always newest version; distributions usually tend
> to stick with a specific version and only apply security fixes).

OK, the origin of your problem becomes clearer.  You can hardcode these
paths into the executables by doing something like

 	env	CFLAGS='-I/my'ssl/include' \
 		LDFLAGS='-L/your/ssl/lib -Wl,-rpath,/my/ssl/lib' \
 		configure ...

I use this myself (except the -Wl part since these libs are
symlinked to my shared library path).  I think "-R/my/ssl/lib"
might also be synonymous with -Wl,...

> Dovecot is the only package I know of where there are like a thousand
> places to put additional libs in the Makefile.am files, but most of
> them are totally ignored by configure.

I don't have that problem -- I use configure to tell dovecot where to find
my self-compiled openssl, and the resulting executables load from where I
want.

Joseph Tam <jtam.home at gmail.com>