CMake cannot find OpenSSL [duplicate] - android

This question already has answers here:
Android CMake: Could NOT find OpenSSL
(4 answers)
Closed last month.
This seems like a frequent issue but I can't figure it out...
I'm trying to compile some libraries which use OpenSSL. They use CMake and are unable to find OpenSSL, even though I made a local build of BoringSSL and set OPENSSL_ROOT_DIR to its install directory.
To work on the issue more easily, I made a test CMakeLists.txt, here it is completely:
cmake_minimum_required(VERSION 3.22.1)
project(test)
find_package(OpenSSL REQUIRED)
This fails with:
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY
OPENSSL_INCLUDE_DIR)
I do have OPENSSL_ROOT_DIR environment variable set to the install directory inside my local BoringSSL build:
% echo $OPENSSL_ROOT_DIR
/Users/[...]/deps/boringssl/cmake-build-debug-arm64-v8a/install
The files are there:
% ls $OPENSSL_ROOT_DIR/include/openssl/ (main|…6)
aead.h cipher.h engine.h
....... ssl.h
% ls $OPENSSL_ROOT_DIR/lib (main|…6)
libcrypto.a libssl.a
I that know CMake (specifically FindOpenSSL.cmake) looks for openssl/ssl.h under include like this:
find_path(OPENSSL_INCLUDE_DIR
NAMES
openssl/ssl.h
${_OPENSSL_ROOT_HINTS_AND_PATHS}
HINTS
${_OPENSSL_INCLUDEDIR}
${_OPENSSL_INCLUDE_DIRS}
PATH_SUFFIXES
include
)
I even hacked FindOpenSSL.cmake to print out _OPENSSL_ROOT_HINTS_AND_PATHS here it is:
STATUS,*** Hints and paths = HINTS;/Users/[...]/deps/boringssl/cmake-build-debug-arm64-v8a/install;ENV;OPENSSL_ROOT_DIR;PATHS
Which has the right path already, plus it refers to the OPENSSL_ROOT_DIR environment variable.
And yet I still get the error.
This seems almost magical and in a bad way. Any ideas?
I've tried using cmake 3.22.1 from the Android SDK and the native (MacOS) cmake 3.24.3, both error out the same way.
Also tried:
set(OPENSSL_ROOT_DIR .......)
right CMakeLists.txt, same error. Magic!
Update
The error is caused by
-DCMAKE_TOOLCHAIN_FILE=${ANDROID_NDK_ROOT}/build/cmake/android.toolchain.cmake
If I remove it, the error goes away.
Yes I'm trying to compile for Android. So the Android toolchain is somehow messing up CMake's ability to find OpenSSL. I am using the latest NDK, 25.1.8937393.

There is detailed description of why this happens here:
Android CMake: Could NOT find OpenSSL
This works for me:
list(APPEND CMAKE_FIND_ROOT_PATH "$ENV{OPENSSL_CUSTOM_ROOT_DIR}")
find_package(OpenSSL)

Related

crystax: sqlite/3/Android.mk: Cannot find module with tag 'openssl/1.0.2h'

I'm trying to build an Android project with crystax ndk within Android Studio, but I got the following error message:
Android NDK: /.../crystax-ndk-10.3.2/sources/sqlite/3/Android.mk: Cannot find module with tag 'openssl/1.0.2h' in import path
I searched the crystax-ndk-10.3.2 folder, and found there is a sources/openssl/1.0.1p folder instead of 1.0.2h.
It looks like sqlite/3 is refering to a 'wrong' version of openssl. But strangely there isn't any reference to openssl in sqlite/3/Android.mk file at all. And I really have no clue why this is happening as I downloaded a brand new crystax-ndk-10.3.2 copy and didn't alter any bit of it. I googled crystax sqlite cannot find openssl and it seems no others are having this problem.
Could anyone please help me find out what's wrong? The following are some details of configurations:
Gradle version: 2.1.2
Android Studio: 2.2.3
crystax-ndk : 10.3.2
OS : macOS Sierra 10.12.2
Special thanks to Alex, I finally figured out what's going wrong.
Basically, after extracting the CrystaX package, one also needs to build openssl, and copy built files into .../sources/openssl/ folder.
I used the following steps from this instruction to solve it:
git clone https://github.com/crystax/android-vendor-openssl.git
cd crystax-ndk-$CRYSTAX_NDK_VERSION
./build/tools/build-target-openssl.sh ../android-vendor-openssl/
cp sources/openssl/1.0.1p/Android.mk sources/openssl/$OPENSSL_VERSION/Android.mk

ERROR: '__NDK_FPABI__' does not name a type. Version 2

I have exactly the same problem described here ERROR: '__NDK_FPABI__' does not name a type but I don't understand the answer or I am doing it wrong; I need more details.
This is my enviroment:
Trying to compile a .so (thridparty) in order to use it in my Android app. This is a standalone lib, not in any Android project (not in project/jni)
Host OS: Ubuntu 12.10 x86
Android NDK version r9d
What I have done is:
Open lib.so's Makefile -> change paths to /usr/include to $NDK_HOME/platform/android-9/arch-arm/usr/include (in previous link, I don't understand the meaning of "Android makefile")
Add LOCAL_CFLAGS += -save-temps
So, I don't understand the meaning of "Android makefile" in this standalone lib and where to search (and what to look) the *.i *.ii *.s files
Any help? Thank you
P.D: I would like to comment in related topic but I don't have enough reputation. Sorry
I have solved the problem linking header file (sys/cdefs.h) from $NDK_HOME/platform/android-9/arch-arm/usr/include/sys to $NDK_HOME/platform/android-9/arch-arm/usr/include
and changing the source file that launches the error from #include <sys/cdefs.h> to #include <cdefs.h>
Sure there must be better solution, but this was enough for me.

Javah cannot find khronos.opengles.GL10

There are similar questions addressed here, such as this one, but I've already checked their answers and, after implementing them, javah is still unable to find the javax.microedition.khronos.opengles.*; configuration.
I have my classpath (in eclipse) edited to include the Android SDK API 10 .jar file, so this should work. Is there an external environment variable I need to edit? I've already tried echoing out $CLASSPATH, which appears to be blank, so I have no idea what the issue is here,
and after exporting it to the location of my android.jar file, it still doesn't work.
Thus, I'm at a loss here as of what to do.
What could be done to solve for this? It appears the only issue really is this library, and nothing else.
For android-ndk-r8b and windows 7( 64 bit ) you must write -bootclasspath and point exactly to android.jar file and optionally -classpath. for example:
javah -classpath bin/classes -bootclasspath "C:\android-sdk\platforms\android-8\android.jar" com.example.SanAngeles.DemoRenderer

Android C library built on OS X and "ranlib: warning for library..."

When I tried to build my c library on OS X 10.7.3, I use android-sdk-mac2.2, sdk tools version is 12, and use android-ndk-r6. When I finished my compiling it said :
ranlib: warning for library libsystem.a the table of contents is
empty (no object file members in the library define global symbols)
I tried to use this libsystem.a, and it said could not read symbols: Archive has no index , run ran lib to add one.
Is anyone knowing why? And what should I do to compile successfully ?
Thanks very much .
Not sure if this is your situation, but the Makefile I was using hard-coded ranlib to /usr/bin/ranlib. Apparently the Mac ranlib is not compatible with the Android ranlib.

How to build Android NDK sample: "bitmap-plasma"

I am trying to build the bitmap-plasma sample that is included with the ndk, but getting an error. I run ndk-build from the samples/bitmap-plasma directory, and the error it displays is that it cannnot locate android/bitmap.h file.
How do i direct the ndk-build script to the file it needs?
Using android-ndk-r4 on Ubuntu Lucid 10.04
Well it's working now, so in case anyone was having my same problem:
There as an android-ndk-r4b bugfix release today, which it seems no longer has this problem.
Available to download here.
http://developer.android.com/sdk/ndk/index.html
With Ubuntu 10.04 and NDK r5b, I have just posted a bug report (with the fix included) for build_platforms.sh. See http://code.google.com/p/android/issues/detail?id=15180 for details. Essentially, the local declarations in the symlink routine must be amended. Otherwise, it only links the first file (alphabetically) from each directory, and truncates the remainder from the list.
Correcting this allowed the symbolic links to be fully populated, thereby filling in the missing header files and libraries and allowing the samples to build successfully.

Categories

Resources