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>