Austin English
2015-Nov-10 04:23 UTC
OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote:> On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote: >> Howdy, >> >> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the >> ssl implementation. Unfortunately, this fails to work (tested on >> Debian Unstable and Gentoo): > [...] >> conftest.c:225:4: warning: implicit declaration of function 'exit' >> [-Wimplicit-function-declaration] >> exit(1); >> ^ > > These things are noise. I'll fix them, but they're not the cause of > your problem.Sure, just wanted to be complete.>> ./conftest: error while loading shared libraries: libcrypto.so.35: >> cannot open shared object file: No such file or directory > > This is the problem: configure is telling the linker to link against > libcrypto in the libressl directory but you have not told the runtime > linker to look there for shared libraries, so your binaries (in this > case, the configure test) fail at runtime. > > To fix this you probably want to either: > - add /opt/libressl-2.2.4/lib to /etc/ld.conf or /etc/ld.conf.d/ and > run ldconfig > - remove the .so files from /opt/libressl-2.2.4/lib so that the > linker will pick up the static libcrypto.I tried removing the .so's, but openssh then falls back to the system openssl instead of the specified ssl. The .a's are present (I also tried explicitly building libressl with --enable-shared, but that made no difference).>> doing: >> export LD_LIBRARY_PATH=/opt/libressl-2.2.4 >> >> Works around this issue, and allows OpenSSH to compile (though some >> tests fail that don't with openssl-1.0.2d. > > That'll help anything that inherits the environment, but anything that > sanitizes its environment (eg sudo) will fail, and the resulting > binaries won't work without the environment variable. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement.-- -Austin
On Mon, Nov 09, 2015 at 22:23:12 -0600, Austin English wrote:> On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote: > > On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote: > >> Howdy, > >> > >> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the > >> ssl implementation. Unfortunately, this fails to work (tested on > >> Debian Unstable and Gentoo): > > [...] > >> conftest.c:225:4: warning: implicit declaration of function 'exit' > >> [-Wimplicit-function-declaration] > >> exit(1); > >> ^ > > > > These things are noise. I'll fix them, but they're not the cause of > > your problem. > > Sure, just wanted to be complete. > > >> ./conftest: error while loading shared libraries: libcrypto.so.35: > >> cannot open shared object file: No such file or directory > > > > This is the problem: configure is telling the linker to link against > > libcrypto in the libressl directory but you have not told the runtime > > linker to look there for shared libraries, so your binaries (in this > > case, the configure test) fail at runtime. > > > > To fix this you probably want to either: > > - add /opt/libressl-2.2.4/lib to /etc/ld.conf or /etc/ld.conf.d/ and > > run ldconfig > > - remove the .so files from /opt/libressl-2.2.4/lib so that the > > linker will pick up the static libcrypto. > > I tried removing the .so's, but openssh then falls back to the system > openssl instead of the specified ssl. The .a's are present (I also > tried explicitly building libressl with --enable-shared, but that made > no difference).This is actually an old issue that predates LibreSSL. The static library is not compiled with -fPIC, so it it unusable by OpenSSH when the build-hardening options are enabled. If you rebuild LibreSSL with CLFAGS=-fPIC and also supply --disable-shared to ./configure, OpenSSH should be able to build. Alternatively, you could disable the build hardening in OpenSSH, but that seems like a step backwards.> > >> doing: > >> export LD_LIBRARY_PATH=/opt/libressl-2.2.4 > >> > >> Works around this issue, and allows OpenSSH to compile (though some > >> tests fail that don't with openssl-1.0.2d. > > > > That'll help anything that inherits the environment, but anything that > > sanitizes its environment (eg sudo) will fail, and the resulting > > binaries won't work without the environment variable. > >Another alternative would be to pass -Wl,-R/opt/libressl-2.2.4/lib to the compiler to embed the search path in the headers of the executables. You could add --with-ldflags=-Wl,-R/opt/libressl-2.2.4/lib to the configure options to OpenSSH. It might be nice if this option was added automatically be configure, but I don't know if it's sufficiently portable to be worthwhile. -- Iain Morgan> > -- > > Darren Tucker (dtucker at zip.com.au) > > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > > Good judgement comes with experience. Unfortunately, the experience > > usually comes from bad judgement. > > > > -- > -Austin > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev-- Iain Morgan
Carson Gaspar
2015-Nov-10 20:41 UTC
OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
On 11/10/2015 12:19 PM, Iain Morgan wrote:> Another alternative would be to pass -Wl,-R/opt/libressl-2.2.4/lib to > the compiler to embed the search path in the headers of the executables. > You could add --with-ldflags=-Wl,-R/opt/libressl-2.2.4/lib to the > configure options to OpenSSH.This is that "standard" hack for projects that hate RPATH> It might be nice if this option was added automatically be configure, > but I don't know if it's sufficiently portable to be worthwhile.This is (IMNSHO) the correct fix, and there are autoconf modules to determine the toolchain specific linker options, or libtool will correctly handle "-mode=link -rpath /some/path" arguments. If you wanted the library found by the standard linker path, why would you specify its location in the configure args? -- Carson
Austin English
2015-Nov-11 00:13 UTC
OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
On Tue, Nov 10, 2015 at 2:19 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:> On Mon, Nov 09, 2015 at 22:23:12 -0600, Austin English wrote: >> On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote: >> > On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote: >> >> Howdy, >> >> >> >> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the >> >> ssl implementation. Unfortunately, this fails to work (tested on >> >> Debian Unstable and Gentoo): >> > [...] >> >> conftest.c:225:4: warning: implicit declaration of function 'exit' >> >> [-Wimplicit-function-declaration] >> >> exit(1); >> >> ^ >> > >> > These things are noise. I'll fix them, but they're not the cause of >> > your problem. >> >> Sure, just wanted to be complete. >> >> >> ./conftest: error while loading shared libraries: libcrypto.so.35: >> >> cannot open shared object file: No such file or directory >> > >> > This is the problem: configure is telling the linker to link against >> > libcrypto in the libressl directory but you have not told the runtime >> > linker to look there for shared libraries, so your binaries (in this >> > case, the configure test) fail at runtime. >> > >> > To fix this you probably want to either: >> > - add /opt/libressl-2.2.4/lib to /etc/ld.conf or /etc/ld.conf.d/ and >> > run ldconfig >> > - remove the .so files from /opt/libressl-2.2.4/lib so that the >> > linker will pick up the static libcrypto. >> >> I tried removing the .so's, but openssh then falls back to the system >> openssl instead of the specified ssl. The .a's are present (I also >> tried explicitly building libressl with --enable-shared, but that made >> no difference). > > This is actually an old issue that predates LibreSSL. The static library > is not compiled with -fPIC, so it it unusable by OpenSSH when the > build-hardening options are enabled. If you rebuild LibreSSL with > CLFAGS=-fPIC and also supply --disable-shared to ./configure, OpenSSH > should be able to build. Alternatively, you could disable the build > hardening in OpenSSH, but that seems like a step backwards.This does work, thanks for the tip!>> >> doing: >> >> export LD_LIBRARY_PATH=/opt/libressl-2.2.4 >> >> >> >> Works around this issue, and allows OpenSSH to compile (though some >> >> tests fail that don't with openssl-1.0.2d. >> > >> > That'll help anything that inherits the environment, but anything that >> > sanitizes its environment (eg sudo) will fail, and the resulting >> > binaries won't work without the environment variable. >> > > > Another alternative would be to pass -Wl,-R/opt/libressl-2.2.4/lib to > the compiler to embed the search path in the headers of the executables. > You could add --with-ldflags=-Wl,-R/opt/libressl-2.2.4/lib to the > configure options to OpenSSH. > > It might be nice if this option was added automatically be configure, > but I don't know if it's sufficiently portable to be worthwhile.Yes, it would. OpenSSH(p) runs on more platforms than I'm familiar with, so I can't say :)> -- > Iain Morgan > >> > -- >> > Darren Tucker (dtucker at zip.com.au) >> > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 >> > Good judgement comes with experience. Unfortunately, the experience >> > usually comes from bad judgement. >> >> >> >> -- >> -Austin >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- > Iain Morgan-- -Austin