On Sun, 9 Feb 2014, Karl Berry wrote: > I think it's probably more likely to do with the -fPIE option - this > requires that the libraries linked be position independent too. > > The fact is that when I used --without-hardening, the link succeeded > without any other changes. I don't believe any -fPIC option is being > used anywhere in my scenario. --without-hardening turns off PIE too > I'd recommend rebuilding OpenSSL with -fPIC instead, > > There are various reasons why I don't want to do that, but that's > irrelevant. The point is that linking with a static libssl always > worked before; hence I thought it worth mentioning. If it's not going > to be supported (I hope you won't go that route, of course), then it > should bomb out intentionally, not just because some random test > happened to fail. --without-hardening will continue to be supported, but toolchain hardening will continue to be the default. It's hard and fairly platform-dependent to provide better diagnostics for why linking against OpenSSL fails and IMO not worth it given config.log gives a pretty clear reason. > Another possibility would be to avoid the relro option unless the > library is dynamic, or make it a separate configure option, or > whatever. I believe that is the one that's the issue, and the others > are fine. pretty sure it isn't relro, you can verify by editing it from Makefile afrer configure has run. You could also try --without-pie to turn PIE off and leave relro intact. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
