My application uses Here SDK and Twilio SDK. Both uses native libraries (Here SDK with native libraries locally plugged in from /libs and /jniLibs folders, Twilio SDK plugged in from jCenter). But on Android 5.1 Here SDK throws exception "MISSING LIBRARIES: libMAPSJNI.so" although this library present in result APK. I opened folder where my program is installed on device and compared content in two cases: with or without Twilio SDK. The difference is that when connected Twilio API folder /lib is a file, and for obvious reasons, the loader can not see inside it native libraries needed initialize Here SDK. If remove the Twilio gradle dependency the assembly occurs normally. What could be a reason and how to fix it? If needed I can attach test project with these libs
You need to modify your build.gradle like this:
android {
(...)
splits {
abi {
enable true
reset()
include 'armeabi-v7a'
universalApk false
}
}
(...)
}
It's probably because Twilio SDK supports x86 and HERE SDK currently doesn't support it.
By defining a splits block you can tell Gradle to create APKs for each listed ABI:
include "armeabi", "armeabi-v7a", "x86", "mips"
Alternatively you can include all desired ABIs into one APK by adding the following filter:
android {
(...)
defaultConfig {
(...)
ndk {
// allow only 32bit *.so libs
abiFilters "armeabi", "armeabi-v7a", "x86", "mips"
}
}
}
Both approaches will exclude 64bit functionality that might clash with the 32bit HERE SDK, but the latter will support more devices with a single APK.
Some libraries, like the new Android Room Persistence library, add 32bit flavors along with the two 64bit ABI flavors arm64-v8a and x86_64. Since HERE SDK at the moment only provides a 32bit lib it should be safe to exclude 64bit lib variants. On the other hand it is expected that 64bit devices can gracefully handle 32bit libs.
Related
I've a WIN32 application with a '.exe' where I use the webView2 library with its different object (CreateCoreWebView2EnvironmentWithOption, get_corewebview2,...).
I use also the "ImplementationLibrary" library in the application.
I would like to test my application on another computer (with Windows 10 and system 64 bits) by copying all necessary dll's. Which is the dll's necessary to test my application on another computer for WebView2 and ImplementationLibrary ? In which directory of my computer have I to take the dll library or other files ?
For a Win32 C++ app, in addition to whatever files are required by your application directly, WebView2 requires you also ship the WebView2Loader.dll. You should be able to find it in your build folder along side your app executable. See the Files to ship with the app document.
Additionally you'll need to install the WebView2 Runtime on the target machine. You can either install a non-stable channel version of the Edge browser or Install the WebView2 Runtime.
I have written windows gui application using qt and i want to deploy it.Now when i place .exe to other PC it shows error which says that qt5core.dll and etc required.I can install this dll,but is it possible to run exe app with qt without qt's dll as one file?So i can for example give .exe to my friend and he can instantly run it without installing .dll?
Basically, if you want a single exe file, you probably mean static linking.
The legal commercial version makes it possible or if I am not wrong, you will have to build a static qt version.
In the latter case, you will have to provide the source code of your application.
I do this sometimes, but you'll have to be careful with the license requirements: if you go with GPL, it should be OK, if you choose LGPL, it may be a bit less simple. No idea about the commercial version.
What you must do is building Qt statically, and then use that Qt build to build your application. I had a good experience with mxe. MXE builds an entire crossbuild environment and allows you to build your big Qt exe statically. I used it on Mac OS and Linux to build static executables for Windows, but you can probably run it on WSL. It takes a bit to compile, but it is simple to use. Please note that it cannot be used if your app needs QtWebEngine as it won't build with mingw.
Another simpler option is to create an installer. The Qt installer framework is simple to use. If you include the VS runtime, you end up with a single exe to distribute (the installer).
You always need to include the libraries you use (including your compilers runtime libraries in fact) when you deploy your executable - otherwise how would your application be able to use the code in those libraries? You may be able to statically link some/most things, but rarely everything. Look into how to create an installer / package for your application, so you can bundle up everything as one convenient file.
You can buid you app using QT Static (a large .exe file, no external dependencies)
If you are using LGPL Qt, you must read this:
https://www.qt.io/faq/3.7.-what-are-my-obligations-when-using-qt-under-the-lgpl
Yo can use Qt and static linking, but "The user of your application has to be able to re-link your application against a different or modified version of the Qt library"
You can use an application template like this, very useful for LGPL Qt:
https://marketplace.qt.io/products/qt-lgpl-app-template
I have a project of which I want to develop (and build/release to internal nuget) on Windows. There are multiple versions of my assembly (NET40, NET20, etc) that are created as part of my build process.
I have a new project that wishes to use my libraries on Mono and MonoTouch. Is it possible to build libraries on Windows that are ready to run on MonoTouch/MAC? Note that I do not wish to program against any MonoTouch.dll or Apple/iOS specific libraries. My assemblies are strictly .NET libraries.
Is changing my target framework to .NET 4.0 "Client Profile" sufficient to get support on Mono platforms (including MonoTouch/iOS)?
You can use portable class library's to do this. there is a great article on how to get this set up.
It is quite easy to get set up thanks to the great write up by #slodge on twitter.
I made a little app and built a release version. Now I want to upload it to my site. I have never done this before with Qt, so I'm unsure as to what I should include along with the binary.
How do I figure out which DLLs should be included with my app? And where do I get them? I'm running Windows, but I'd also like to know what I should do in case I want to release a Linux version.
For windows:
You can use dependency walker to see what Qt libraries (or others) you should ship. This is the depends.exe executable that is included with Visual Studio, but you can download it separately from: http://www.dependencywalker.com/
Load your app into that and it will list out all the modules it expects at runtime. You might also have to ship a Visual C++ Runtime Redistributable compatible with the compiler that you built the executable with (if it's VC++).
Do note that dependency walker does not account for things like Qt's plugins. An example of this would be the QtAssistant system (for help menu-type functionality), which as of Qt4 relies on Qt's sqlite functionality, which is typically built as a plugin (qtsqlite4.dll if I remember).
For Linux:
This is trickier because of wider disparities in Linux distributions. You can of course use the GNU build system if you want to ship source, but if you're shipping binaries, and want to support a variety of distros, you might do best to build packages for each platform you want to release on.
In my past, a company I worked for switched to using cmake and after setting up all the project and build files, used that to generate builds and packages for different OSes. On Windows, this meant hooking in with Inno Setup, and for Unix-like systems, cmake knows how to generate things like installable shell scripts. Definitely made life much easier.
Our QA department would test our software in virtual machine instances of our supported platforms, completely clean, and see if anything was missing.
If you're talking about DLLs, I assume it is about Windows.
Use Dependency Walker to see the DLL dependencies.
Or... take a clean system, with no dev tools installed, and put your executable, try to run it there, and see what DLLs are reported as necessary and inexistent. Put the DLLs near the executable.
For a Linux version, you can either create platform targeted releases of installers for each Linux fork or you can let people compile from source. If your app is new, the only way you get exposure is supply people with readymade installers, the targeted installers. New users loathe compiling packages from source.
You can try debian (.deb) and redhat (.rpm) packages first. These two are extremely popular lines and will let you have a taste of things.
I am in the process of writing an application to communicate with Usb devices using WinUsb.dll. This is a user-mode library that allows communication with a device through winusb.sys installed as its driver in the kernel.
I am writing this application in C++ with Visual Studio 2008.
The header WinUsb.h is found in the Windows DDK so I add the include path "D:\WinDDK\7100.0.0\inc\ddk". I then get an error that Usb.h cannot be found which WinUsb.h includes, Usb.h is also in the ddk but in a different directory, so I add "D:\WinDDK\7100.0.0\inc\api" as an include dir.
Once I add that path then everything goes in the toilet and I start getting compile errors in stdio.h and a bunch of other weird places.
I really don't want to use the DDK build system and compiler in order to simply use this DLL, thats one of the main reasons I'm using WinUsb instead of writing a proper driver.
Has anyone built an application using WinUsb.dll and Visual Studio?
I am working on writing a cross-platform USB library and using the DDK build environment would make my build process much more complicated.
WinUsb is meant to be used by client applications for devices who load WinUsb.sys as their driver. However there doesn't seem to be a version of the WinUsb headers packaged for use in user-mode programs (not including UMDF drivers).
What I ended up doing was copying the few headers that support winusb.h out of the DDK and into a private directory, I then reference that directory as an include directory during the build.
These are the headers I needed to copy:
POPPACK.h
PSHPACK1.h
usb.h
usb100.h
usb200.h
winusb.h
winusbio.h
Once I had these included in a private directory and linked with winusb.lib in the DDK I was able to compile and run my project in Visual Studio.
I don't know if I'd recommend this method as it could be bad when the headers change between DDK releases, but I will open a CONNECT bug to see if I can get MS to create a package of WinUsb headers for use in client user-mode applications.
Historically the DDK and the SDK haven't played well together, but that problem was fixed sometime before Vista was released. However, it seems like you might be mixing parts of one SDK with another, which isn't good. I'd either use the DDK build environment or at least take a look at the INCLUDE path the DDK environment sets up and replicate it exactly in the VS project settings.
Note that you can use the DDK build environment and still use the VS IDE by creating a 'makefile project' or you might be able to use something like OSR's or Hollistech's DDKBUILD tools:
OSR's: http://www.osronline.com/article.cfm?article=43
Hollistech's: http://www.hollistech.com/Resources/ddkbuild/ddkbuild.htm
I haven't used these, so I'm not sure how well they work, but note that in spite of their similar names and uses they are different tools.