[LEDE-DEV] [PATCH] tools/cmake: Fix building with openssl libs in non-default location

Alexey Brodkin Alexey.Brodkin at synopsys.com
Mon Sep 19 08:49:34 PDT 2016


Hi John, Felix,

On Thu, 2016-09-15 at 23:21 +0300, Alexey Brodkin wrote:
> Hi John,
> On Thu, 2016-08-18 at 09:40 +0200, John Crispin wrote:
> > On 17/08/2016 16:53, Alexey Brodkin wrote:
> > > On Wed, 2016-08-17 at 16:51 +0200, John Crispin wrote:
> > > > On 17/08/2016 16:49, Alexey Brodkin wrote:
> > > > > On Wed, 2016-08-17 at 09:20 +0200, John Crispin wrote:
> > > > > > On 16/08/2016 12:43, Alexey Brodkin wrote:
> > > > > > > For some reason CMake's buildsystem searches for openssl libs
> > > > > > > on Linux either in /usr/libX, /usr/local/libX or in OPENSSL_ROOT_DIR
> > > > > > > ignoring standard LD_LIBRARY_PATH env var.
> > > > > > > 
> > > > > > > This behavior breaks CMAke building if openssl libs are in some
> > > > > > > specific location like ~/.local/lib etc.
> > > > > > > 
> > > > > > > Solution is simple set OPENSSL_ROOT_DIR env var before calling
> > > > > > > CMake's configure script. Now openssl libs if they exist in
> > > > > > > $(LD_LIBRARY_PATH) will be used. What's also nice libs from
> > > > > > > LD_LIBRARY_PATH will be used instead of system ones (if they exist).
> > > > > > > 
> > > > > > 
> > > > > > this looks like a very specific hack for a non generic issue.
> > > > > 
> > > > > And indeed it is. That's for a case if user wants to use libs from
> > > > > LD_LIBRARY_PATH instead of default system locations.
> > > > > 
> > > > > > 
> > > > > > ll 
> > > > > > 
> > > > > > looking at
> > > > > > Modules/FindOpenSSL.cmake i would claim that your pkconfig fails to
> > > > > > hounor the libs in your home folder and thus the path detection fails.
> > > > > > might be better to fix the pkgconfig issue ?
> > > > > 
> > > > > Again pkconfig points to stuff installed in system but if user wants to
> > > > > use libs from some custom location which was added in LD_LIBRARY_PATH
> > > > > it won't work without the patch.
> > > > 
> > > > how about using PKG_CONFIG_PATH ?
> > > 
> > > But this env var points to pkgconfig script but not libs itself, right?
> > > 
> > > -Alexey
> > > 
> > 
> > you need to find a way to tell pkgconfig to honour the pc files in your
> > home folder i guess
> 
> So I spent some more time looking at that problem.
> 
> What happens is OpenWRT/Lede uses its own pkg-config (staging_dir/host/bin/pkg-config)
> which looks for .pc-file in "staging_dir/host/lib/pkgconfig/".
> 
> That's what I have there:
> ------------------------->8--------------------------
> ls staging_dir/host/lib/pkgconfig/
> expat.pc
> liblzma.pc
> uuid.pc
> ------------------------->8--------------------------
> 
> That means cmake cannot use pkgconfig for getting info about libssl/libcrypto and then
> it starts to search in "/usr/local/lib" before looking in "/usr/lib64".
> 
> Now on the server I'm trying to use and where unfortunately I have no admin rights
> in "/usr/local/lib" there's "libcrypto 0.9.8" while "libssl of version 1.0.1e" exists in "/usr/lib64"
> (right next to libcrypto of the same version).
> 
> Essentially that my setup is strange (let's call it that way) and on other machines which
> I manage myself there's no such discrepancy still I think it may worth fixing so others won't
> bump into same problem.
> 
> IMHO the most robust solution would be to build OpenSSL for host in OpenWRT/Lede and install
> .pc-file in "staging_dir/host/lib/pkgconfig/". That way we'll be more independent from system libs.

So with help of our IT guys I was able to get both libssl and libcrypto of the same version in /usr/local/lib
but now another problem hits me. CMake determines openssl version reading opensslv.h file where ever it is found.

In my case there're no headers in "/usr/local" tree instead there's one in "/usr/include/openssl" which is a part
of openssl 1.0.1x installation that exist in "/usr/lib64" folder.

So in absence of libssl.pc in "staging_dir/host/lib/pkgconfig/" it is a real nightmare to get
cmake configured and built with multiple openssl versions installed on the host.

In that light I'm wondering why don't we build openssl for host?
What's even more interesting why OpenSSL building for host was once introduced in
https://git.lede-project.org/?p=source.git;a=commit;h=c8ad508d37297400364ee276733de90d29e94778
and almost immediately after was reverted by
https://git.lede-project.org/?p=source.git;a=commit;h=82c182f828b3741c494d9014cedb9d0edd9af94e
?

Anyways just to document it here my problem could be worked-around locally with:
---------------------->8---------------------
export OPENSSL_ROOT_DIR=/usr/lib64
---------------------->8---------------------
executed before firing-up Lede build process.

-Alexey


More information about the Lede-dev mailing list