I am able to use OpenSSL static libraries (libcrypto.a and libssl.a) in my iOS app thanks to this help. Now i can also use OpenSSL dynamic libraries (libcrypto.so and libssl.so) in my Android app version thanks to this info. I downloaded the files for Android in the OpenSSL_1.0.2g_Android.zip file from here. I just guessed and used the ARM files (armeabi-v7a folder) instead of the Intel files (x86 folder) and it worked on my Android test phone.
My question: How do I make an Android build that uses the correct library files on ARM devices AND also on Intel? I don't know how to deploy both sets of files for this. Below is snip of project window showing where i test added the second libcrytpo.so library file for x86.
But, this second libcrypto.so does not show up in the deployment window, only the first version i added (the ARM version) remains.
I was hoping i could somehow use compiler directives but maybe i just need 2 independent projects altogether? One built for Android ARM and other for Android x86? Further, all i'm needing in my code is an IdHTTP1->Get() so maybe their is a way i can use the built in BoringSSL fork? If so, how?
russ
C++Builder 10.3 Version 26.0.33219.4899
RAD Studio does not support producing Android apps for Intel, only for ARM, so don't even worry about trying to use the x86 libs on Android.
Also, Indy does not support BoringSSL at this time.
Related
In my Visual Studio Xamarin Forms iOS project, I am linking against a native (c++) library I built and deployed using Visual Studio Cross C++ Platform. I can link and run against an actual device (through the Mac Server), but I cannot get it to work through the simulator. If I build with the same link settings, the build fails, not being able to find the entrypoint. If I choose not to link, then the build succeeds but I get am Entrypointnotfoundexception when running at the point where I try to call into the native code.
I just went through the example from your comment, using his sample code here. I had to do a couple things to get it to run correctly. My problem was on Xamarin.iOS, but the same steps can be applied for Xamarin.Forms, assuming you already have platform-specific integration working.
Since you have the code working on a physical device, you should already have a Native Static Reference to your .a library. But the iOS simulator runs on the x86_64 architecture (iOS 11 and later does not support i386), while your device likely runs on some version/variant of ARM. It sounds like your library is built to support only your device's architecture. You can check this by running lipo from your Mac:
% lipo -info /usr/lib/libCLib.iOS.a
To support the sim's architecture as well (see this article), build the C++ project to the architectures you need to support, then combine them, like so:
lipo -create -output libCLib.iOS.a libCLib.iOS-x8664.a libCLib.iOS-arm64.a
Use that output .a file as your new Native Static Reference file back in Visual Studio. Change Supported Architectures in your project settings to x86_64, and that should be everything. Hope this helps somebody.
I have a Xamarin.Android application that is being built through a build server. The application is targeting API Level 23 and Min Android Version 4.1 (API 16). During debug the application works fine, but when the build server compiles the application, packages it, signs, and aligns it, it crashes on load with the error:
Unable to get provider mono.MonoRuntimeProvider: java.lang.RuntimeException: Unable to find application Mono.Android.Platform.ApiLevel_23 or Xamarin.Android.Platform
Most phones result in an immediate crash with the error mentioned above, but a handful of devices work fine. The only thing those devices have in common is they were used to deploy the application during development. This leads me to believe they have the shared run time installed and hence why it doesn't fail. The build server has the latest Xamarin.Android (just like the dev machines), latest Java, latest JDK, and latest Android libraries (per the SDK Manager). The configuration being built doesn't use the shared runtime, it is not linking (although I also tried it with linking SDK assemblies only), and it only supports armeabi-7va ABI.
What am I doing wrong?
I have finally found the problem which seems to be a bug with Xamarin (or Mono?). We have AndroidManifest.xml and AndroidManifestAlpha.xml. During the build we specify /p:AndroidManifest=Properties/AndroidManifestAlpha.xml to the MSBUILD arguments, but the compilation adds all the activity, services, and mono information to the AndroidManifest.xml file only. The build eventually uses the specified AndroidManifestAlpha.xml file and compiles the APK without the mono runtime; resulting in the error mentioned above.
Change the Target Android version. In VisualStudio on Mac, the path is Project->.Options->General->TargetFramework.
If someone finds this error check my answer in another post:
https://stackoverflow.com/a/52678522/1106547
It's for Xamarin Studio, but I guess should work for VS Xamarin extension too.
The main idea in my case was to put android-25 (or android-23 for the case of the original question) folder to the Android SDK platforms directory.
I suppose it allowed the Xamarin engine to install correct "..Platform.ApiLevel_" APK and use the shared library.
currently I have to port an existing mobile application which runs on Android and IOS to Windows 8. Unfortunately it is using a lot of C++11 Stuff, which is not supported by Windows Phone 8.0. The project itself was written with cocos2d-x 2.0. It contains a C# Part which loads a C++ library with the major part of the application. Also it includes modules from "Project Angle", which is a library to convert OpenGL calls into DirectX calls.
The first thing I tried was to upgrade the project to Windows Phone 8.1 using the 'reassign project' option from Visual Studio. I still had to remove a bit of C++11 Code, but now at least the project itself compiles. After compiling I got some linker errors for functions like 'getenv'. The angle libraries don't even compile and gives me errors like 'Cant find include file vccorlib.h' for every single source file.
Since I'm completely new to Windows development, I don't know if something went wrong on upgrading the projects, or if I have to fix something within the projects. But I tried to upgrade an other project, which was already ported to WP8, and got the same errors.
Now I have to deceide if I have to fix the Windows Phone 8.1 version or if it's easier to remove C++11 Code for 8.0 (which means a few days of work and let my heart bleed)
I also found a compiler update for Visual Studio 2012, which has extended support for C++11, but it seems it's not compatible for Windows Phone.
I hope someone of you could give me a hint, what I have missed for WP 8.1 or has another idea. Thanks for your help!
Cocos2d-x should work on Windows Phone, but you have to get the right version. You can't use pre-built binaries for other platforms (even desktop Windows) and you need to make sure you're building correctly. See the download page.
Visual Studio 2013 Update 4 is the latest stable release of VS that supports Windows Phone projects; you can see the level of C++11 support listed here along with support in the not-yet-finished Visual Studio 2015 compiler.
From what I've heard, it's possible to use a DLL in Windows that is compiled with a different compiler version. Does MacOSX frameworks have the same functionality? That is, can I compile a framework with one compiler and then use that framework in a program that uses a different compiler version?
The reason why I ask is that need to compile a open source project that outputs a framework. That project is not possible to build with gcc4.7 and my code uses gcc4.7 features.
It looks really easy to switch MonoDevelop's compiler to Mono tools instead of .NET – you just need to pick a different framework under settings of the IDE.
However, after switching to Mono and getting the project compiling by Mono tools, Mono for android no longer seems to be an available framework (i.e. the reference to it in the Android project turns red). Obviously, the build fails with tons of errors like Android.XXX.YYY is not a class or namespace name, etc.
Is there a way to install Mono for android on a Windows machine so that it is available to Mono tools and usable from Monodevelop running on Mono?
No. Mono for Android uses the MSBuild build system, and installs custom build tasks and frameworks into the MSBuild extension directories. Mono's implementation of MSBuild (xbuild) has separate extension directories. It might be possible to copy the targets and extensions across but you'd probably run into other issues, as it's completely untested.
In general on Windows I'd recommend using the MS/.NET toolchain in MonoDevelop unless you have a really good reason to use the Mono toolchain. Note that you can run with Mono even if you compile with .NET, using the Run->Run with... menu.