Today I faced a problem. My project needs to use some libraries (*.jar) that use Java 1.8 features. I see more and more libraries use now Java 1.8 features (like webRTC, exoplayer, etc.). In this way, we must do desugaring.
Desugaring allows you to use these features on older devices by replacing new bytecodes and language APIs with older ones during the build process
With d8.bat (replacement of dx.bat), desugaring is turned on by default. So you can now use most of the latest language changes while targeting older devices.
When we compile a project, in the background Delphi does this:
dx.bat --dex --output="C:\Dev\output\libwebrtc-dexed.jar" "C:\Dev\lib\libwebrtc.jar"
And this fails with a library that contains Java 1.8 features.
So Delphi must do this instead:
d8.bat --lib C:\SDKs\android-sdk-windows\platforms\android-28\android.jar --output="C:\Dev\output\libwebrtc-dexed.jar" "C:\Dev\lib\libwebrtc.jar"
Any idea how I can tell Delphi to use d8.bat instead of dx.bat?
I found a solution modifying the "CodeGear.Common.Targets" file (Delphi's bin folder), creating an alternative command to be used only for dex generation using the d8.bat instead of the dx.bat:
1) Close the IDE
2) Edit the "CodeGear.Common.Targets", localize the DxCmd definition, and add this two new lines, creating a new command for d8.bat:
<JavaD8Path>#(JavaAaptPath->'%(RootDir)%(Directory)')d8.bat</JavaD8Path>
<D8Cmd>PATH $(JDKPath)\bin;$(PATH) %26 "$(JavaD8Path)" --output=</D8Cmd>
3) Now localize the target used to generate the dex files and replace the DxCmd by the new D8Cmd
<!-- Generate a "dexed" version of the customized jar files if they doesn´t exists -->
<Target Name="BuildPredexedJar" DependsOnTargets="GetProjectJars">
<Exec Condition="( '#(_JarsLocations)'!='' And !Exists('%(_JarsLocations.PredexedJar)') )"
Command='$(D8Cmd)"%(_JarsLocations.PredexedJar)" %22%(_JarsLocations.FullPath)%22'/>
</Target>
4) Now the dex generation will use the d8.bat compiler, where "desugaring" is turned on by default.
Related
I'm trying to setup the files from LuaBinaries (specifically Lua 5.2.4 64-bit), and there are a few things I'm confused about.
There are two zip files provided, the binaries: lua-*_Win*_bin.zip and the libraries: lua-*_Win*_*_lib.zip
So, these are my questions:
For the libraries, two versions are provided, static and dynamic. What's the difference?
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
For the libraries, two versions are provided, static and dynamic. What's the difference?
The static library can be embedded into your own program. While the dynamic library is linked to your program, so the system will search for it when running your program. If the search for the dynamic library failed, the system won't be able to run your program correctly.
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
The lua*.dll under lua-*_Win*_bin.zip is the dynamic link library(.dll) used by lua.exe and luac.exe. An error will be thrown by Windows if you run lua.exe after deleting it.
Which one should you use? It depends on your purpose. Usually you want to use the static library in you project.
Running different versions of Lua bytecode (e.g., runs the bytecode created by luac v5.1.4 with lua v5.2.4) is forbidden (by checking the header of bytecode files).
Lua sometimes brings breaking changes upon upgrading, and some public APIs vary between different versions. If you build and install Lua from source code, only the binaries and the static library are produced.
Lua is a very tiny language (the static library under Linux is about 356K(v5.1.4) or 440K(v5.3.3), measured by du -sh liblua.a), so embedding the static library with your program is fine for many high-end devices.
If you feel familiar with make command, you can build Lua from source code and load it into your project. Or, just use the static library in your project. (I don't think most Windows users have a lua*.dll in their enviroment.)
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
No, the libxxx.a and libxxx.so is the static and dynamic library naming conventions under *nix systems, like Linux and FreeBSD.
Looking at the cross-platform nature of potrace http://potrace.sourceforge.net/, is it possible to compile this for iOS? If so, how?
Yes, it is possible to compile potrace for iOS.
As a matter of fact, most open source libraries using standard (GNU) configure tools that compile on MacOS X will easily compile on iOS, because they are likely free of platform-specific code (e.g. linuxisms) and standard configure tools allow cross-compilation.
You can compile these libraries in the shell by pointing configure to the proper toolchain and SDKs. Paths changed with Mavericks and Xcode 5, but fortunately automated scripts exist for more popular libraries such as expat.
The proposed solution is based on the x2on/expat-ios project on GitHub. Their script fixes expat's config.sub which doesn't know about arm64 target. Do does potrace 1.11's config.sub. However, a simpler approach consists in downloading a more recent version of config.sub. Unlike expat, potrace doesn't seem to need any patch to compile for iOS.
Full script build-potrace.sh is available here:
https://gist.github.com/pguyot/dce18af64a71b93c0204
Please note that potrace is licensed under the GPLv2. You might want to check Is it legal to publish iOS apps under the GNU GPLv3 open-source license? question.
I have also asked this question on the BlackBerry support forums, under the thread "NoClassDefFoundError while preverify the jar files in BlackBerry"
I am adding a library files(jar files) in my BlackBerry Project and and try to run it. But it is giving me the below error : Error!: Missing stack map at label 77. So i try to find out the issue and find this link: Preverify Link
So i tried to fix this issue using preverifier. As i am using BlackBerry eclipse plugin, i have tried in this way:
Copy the jar file in the bin folder of my eclipse 6.0 plugins (eclipse-SDK-3.5.2-win32\eclipse\plugins\net.rim.ejde.componentpack6.0.0_6.0.0.29\components\bin)
Execute the following command in the command line:
preverify -classpath "<path to 6.0.0.29 SDK>\net_rim_api.jar" "ArcotOTP-Lib-Java-Test-2.0.0.jar"
But after running this line, i am getting the below error:
Error preverifying class Mypackage.API$1
java/lang/NoClassDefFoundError: Mypackage/Test
BlackBerry devices are running on the Java-ME platform, so you can't use modern java features. Typical Java jar files these days use newer features that are not backward compatible with the Java-ME platform. Some projects do go out of the way to be backward compatible, like Bouncy Castle. But that is rare.
This question, duplicated on the BlackBerry forums, was also answered on the BlackBerry forums, which I will capture here:
simon_hain:
and is it a j2me library?
Arindam Mukherjee:
No it is java library..all classes are basically java classes. The same library i am using for android also and it is working fine fro me..
simon_hain:
BlackBerry uses J2ME as a base, Android uses J2SE.
You cannot use an Android library on BlackBerry unless you re-compile it (and resolve all the errors due to missing reflection, lists etc)
I am attempting to get a Native C/C++ library working with Monodroid in the emulator, using DllImport. I am developing mainly in Windows/Visual Studio 2010.
I have built a native C/C++ library (ZeroMQ) using the Android NDK tools, to both x86 and armeabi platforms, using a Ubuntu virtual machine. Is this correct - x86 for emulator and armeabi for the real device? (This is certainly the case on the iPhone/MonoTouch - though in that case statically linked libzmq.a file and DllImport __Internal)
I have added the x86 version of libzmq.so to my MonoDroid project under the directory structure lib\x86\libzmq.so
When I first attempted to build/deploy to the simulator, I got an error 'cannot determine abi type', so I've added x86 to the AndroidNativeLibrary Include="lib\x86\libzmq.so"> project item group. This then deployed.
I have a DllImport for the function to call [DllImport("libzmq"
I've tried libzmq.so, lib/x86/libzmq, lib/x86/libzmq.so etc, but then I call the DllImported method (running in the emulator), I always get a DllNotFoundException.
Can anyone give me some direction?
EDIT: After reading another support answer which states that the emulator uses armeabi .so libraries, I have removed the x86/libzmq and added my lib/armeabi/libzmq.so as an AndroidNativeLibrary. I also removed the project file Abi entry, and indeed the project built and deployed fine.
However, I still get a DllNotFoundException when I try to call a DllImported function. Any ideas?
Many thanks
I don't have any immediate ideas why it isn't working for you; [DllImport("zmq")] should work.
The SanityTests sample exercises the DllImport attribute.
The DllImport: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/Hello.cs#L240
The Android.mk to build libfoo.so: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/jni/Android.mk
Building libfoo.so by calling ndk-build: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/SanityTests.csproj#L82
Including libfoo.so into the .apk: https://github.com/xamarin/monodroid-samples/blob/master/SanityTests/SanityTests.csproj#L96
(This is a repeat of my reply to your email in the ZeroMQ mailing list).
This error could be caused by using an incorrect platform target in your Mono project. I'm not sure if Mono/MonoDevelop supports this, but you probably need to create an ARM platform target, as opposed to x86/x64/Any CPU.
You would experience the same errors if you tried to do P/Invoke interop between an x64-targeted assembly with an x86 native library or vice-versa.
If you're using the clrzmq bindings for bridging Mono and libzmq, you will need to create a new platform target for ARM and rebuild the bindings. The solution only defines x86 and x64 platform targets currently.
Ok, I finally got it working! For whatever reason, ZeroMQ doesn't build correctly using the current/latest NDK r7. The instructions at http://www.zeromq.org/build:android use NDK r6. I also downloaded an old version of the NDK r5b (it was the easiest old version to find a download for), and rebuilt ZeroMQ using it. Result, it now works on emulator and phone!
It apparently used to compile with Borland's C++ Builder, but that was a long time ago. Now I need to get it compiling with bcc32 for use in a bit of code that was /intended/ to be cross-compiler.
Anyone done it already and want to give me some pointers?
Simply modifying the makefile in makefile.bcc appears to be sufficient.
remove the os2/dos check (# Are we under DOS or OS/2?)
set the compiler name to bcc32 instead of bcc
At least the current version (9c) supports C++ Builder out of the box (tested with 10.1).
Navigate to the source directory
Copy jconfig.bcc under name jconfig.h
With C++ Builder 10.3 you need an additional step, because libraries compiled with bcc32 cannot be used with bcc32c projects: Edit makefile.b32 and change the compiler name to bcc32c.
Execute "C:\Program Files (x86)\Embarcadero\Studio\
18.0\bin\make" -f makefile.b32 (replace the path with path to C++ Builder install directory)
Files you need for your project:
libjpeg.lib
All header files