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@gmail.com