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