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

[Alexey Brodkin]

Hi John,

On Thu, 2016-08-18 at 09:40 +0200, John Crispin wrote:
> 
> On 17/08/2016 16:53, Alexey Brodkin wrote:
> > 
> > Hi John,
> > 
> > On Wed, 2016-08-17 at 16:51 +0200, John Crispin wrote:
> > > 
> > > 
> > > On 17/08/2016 16:49, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi John,
> > > > 
> > > > 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.

Any thoguths?

-Alexey