Joseph Tam <jtam.h...@gmail.com> wrote:
>>> 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 ...
>>
>> Based on your mail I've tried CFLAGS/LDFLAGS again, and
>> now Dovecot didn't even compile any longer.
>
> I don't use the same OS as you, but what errors dis you get?
To be exact here, it's not the compiler but the linker failing
(of course, the whole problem is about the linking process).
With "--as-needed", the crypto/ssl libraries are not linked at all with
the object files. I don't quite understand why it doesn't fall back to
the system crypto/ssl libraries because they are in the default pathes
with all other libraries. (That's basically what most other software
packages do if my custom pathes for "-L" "-Wl,-R" somehow get ignored
in the building process.)
IMHO, the unusual option "--as-needed" should be removed. There seems
to be no benefit but it basically keeps Dovecot to be linked against
any custom-specified library.
Maybe it's just a problem with RHEL/CentOS 6 and the GCC that ships
with it. I'm compiling a lot of software myself and link it against
my custom OpenSSL. Never had this problem before, otherwise I would
have known to specify "-Wl,--no-as-needed" to reverse ld's behavior
to the default.
Well, at least I've learned something new. :-)
Regards, Andreas
