On September 30, 2016 at 3:26 AM "Andreas M. Kirchwitz" amk@spamfence.net wrote:
Joseph Tam jtam.home@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
Hi,
The as-needed issue has been hopefully fixed in https://github.com/dovecot/core/commit/f49f1c5fa6a9a55a194e5ada042df13490727...
Aki