I'm hoping someone can give me some help here. I am new to Gluon-mobile and javafxports. We are evaluating Gluon-mobile and are interested in using it on multiple architecture. We are able to run the basic sample program on the Mac laptop and an Android Motorola phone.
However when we try to compile/deploy to an Android device with MIPS architecture we get the error message:
INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries.
Upon investigation, it seems you get this error when you do not have the proper JNI libraries to support the CPU ABI instruction set on the machine you are deploying to. When I unzip the apk file I see under the lib directory:
./armeabi
./armeabi/libactivity.so
./armeabi/libdecora_sse.so
./armeabi/libglass_monocle.so
./armeabi/libjavafx_font.so
./armeabi/libjavafx_font_freetype.so
./armeabi/libjavafx_iio.so
./armeabi/libprism_common.so
./armeabi/libprism_es2_monocle.so
./armeabi/libwebview.so
I believe these are the jni abi libs needed for arm abi. I think we need the same set of libs for MIPS.
Is this supported in gluon/javafxports?
I looked for abi options in the gluon-mobile and javfxports doc but did not find any.
I tried placing this snippet in the build.gradle but it didn't work.
splits {
abi {
enable true
reset()
include 'mips', 'mips64'
universalApk true
}}
Any Ideas?
Thank you,
David
Related
I'm trying to cross-compile a C/C++ program for Windows on Linux.
I've gotten to the point where everything compiles properly, except that x86_64-w64-mingw32/bin/ld is called with the option -lpthread, which doesn't work.
I'm not sure why it's called with that option, because I'm 100% certain that there are no references in the code to threads except through CreateThread, which is part of the Windows API. There's no good reason for mingw to try to link in pthreads if I'm not using them, right?
(Fedora 32 but 64-bit, if it helps.)
There is no way to teach the GCC compiler driver to drop "-lpthread" if the compiler was configured to include pthread support.
I guess you are trying to do a static build (?) and the libpthread.a is not installed by your toolchain.
See a related bug report # https://bugzilla.redhat.com/show_bug.cgi?id=2070571
I was following instructions here and here to build a toolchain which would work on Windows and compile applications for Linux and different hardware platforms. At first I tried to create cross-compiler for i686-linux to test it on a generic Debian 8 system.
Binutils and GCC compiled fine, but I got stuck at Glibc. It told me:
*** The GNU C library is currently not available for this platform.
I see that Sysprogs toolchains are using Newlib instead of Glibc but I haven't found any explanations except that Newlib is a good choice for embedded devices.
Does it mean that Newlib is actually the only choice for Windows -> Linux and that there is no way to compile software which depends on Glibc? Maybe there are "cheats", like copying pre-built Glibc from the target platform or some other workaround?
In theory, I don't even need Glibc built on Windows, I need just some "Glibc compatible stub" built for the target architecture to link (only dynamically, of course) against while compiling for the target platform and OS. Or am I totally wrong here and GCC cannot link to a different C library than GCC itself was linked to?
Or should I forget it and accept the fact that it is impossible (and, most probably, never will be possible) to achieve full Glibc and Linux kernel compatible C/C++ cross-compiling from Windows to GNU/Linux?
I will accept the answer which explains how GCC and Glibc are related and whether it is possible or not to link against Glibc different from C library used when GCC itself was built, and provide some insight about why it is / is not possible.
my guess is you're using --target when building glibc when you really need to use --host (which is different from how newlib is configured -- best to not ask why).
that said, the glibc build system requires a case-sensitive file system as it creates files like foo.oS and foo.os which are very different things. on a system like Windows, that means the build will be corrupted and fail since foo.oS and foo.os refer to the same file. there are patches out there to hack around this, but really you'd be better off booting a VM and doing the toolchain build inside of that.
NB: i'm not saying you need the VM to do all your development. you just need the VM to build the cross-compiler which you'd then run under Windows. this would be a canadian cross build.
rather than do all this yourself by hand, please check out crosstool-ng. it handles/patches/fixes a lot of common errors people make when trying to create cross-compilers.
I want to install intel opencl sdk. And surely I did everything written in intel opencl installation guide in intel's website.
http://software.intel.com/en-us/articles/intel-sdk-for-opencl-applications-xe-2013-release-notes#_Installation_Notes
I did everything written in there but it doesn't work.
Specifically, I can compile the source but it cannot find the platform at clGetPlatformIDs function. error code is -1001 and there's no -1001 error code at cl.h file. If I uninstall, then I cannot compile at all naturally. It means there's error message at compile time that it cannot find lots of functions and defined values. After I install the opencl sdk then there's no message and compile properly. I think it means that install is done properly. But at runtime, it cannot find platform. What's the problem? I've been struggling about one week. Please help me..
---add---
I forgot to let you know my OS.. and so on;;
My OS is Red Hat Enterprise 6.3 (Santiago).
My CPU is Intel Xeon CPU E5-2690.
The code I tried have no problem at other machines and platforms.
Thanks.
I need to compile an old (1992) fortran code. This code run in some SGI IRIX workstation and it was originally compiled with f77. I get errors if I try to compile it with gcc (g77) on my macbook pro or in a ubuntu virtual machine. I wonder if there is some way to get the old f77 compiler (virtual machine, whatever). f2c does not work at all.
Unless it is the case of some vendor extensions which modern compilers do not support (extremelly rare), I don't see why F77 code compilation & build should present any problem at all. Fortran IV or older, maybe, but F77 (within reasonable bounds) should work without much problems.
However, it is hard to suggest anything but a mere list of compilers available without knowing anything about it. The details of the code, the errors that you got, the compile options ... (?)
Please, post some more details.
I sucessfully compiled some fortran77 source code from ~1992 with the Openwatcom Fortran compiler:
http://www.openwatcom.org/
more fortran compilers:
http://www.fortran.com/compilers.html
I'm trying to compile a Mac version of our lib for a customer that wants to include it in a Photoshop plugin, and he is having trouble linking our lib into his app. More detailed info: His plugin is built against the CS4 Photoshop SDK, which means the Mac OS base SDK should be 10.4. My lib is a static one, compiled with the Intel compiler 11.1 and the base SDK is also set as 10.4.
I tested my lib against a small test app I wrote, and it compiles and works fine (on 10.5). To replicate my customer's environment, the app is compiled with gcc, and uses the 10.4 base SDK. While its fine for me, my customer cannot manage to link with my lib. The problem is the following: Undefined symbols:
"_fputs$UNIX2003", referenced from:
_write_message in libMyLib.a(libm_error.o)
When I compile my lib with gcc,and all other project settings the same, its fine, he can generate an executable. As soon as I compile with ICL, it breaks down. Could it be that ICL 11.1 is not compatible with 10.4? On the Fortran compiler forum, I found the following answer:"From the output provided it appears Xcode defaulted to Mac OS X 10.4, which the 11.1 compilers do not support." (http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/68647/)
Does that mean ICL 11.1 does not run on 10.4, or that the code it generates doesn't work on 10.4??
On the following page (http://software.intel.com/en-us/articles/performance-tools-for-software-developers-compatibility-of-intel-compiler-for-mac-os-x-and-xcode/), it also says that ICL 11.1 is not compatible with 10.4 (again same question: what does compatibility mean?). However, it says that ICL 10.1 is, so I tried. But now, even my own test app does not link, for the same reason (undefined function$UNIX2003).
Does anybody know what is the problem, and how to fix it? Or a way to work around it?
Thanks in advance,
A
PS: bonus point if somebody knows what this one means:
ld: absolute addressing (perhaps -mdynamic-no-pic) used in _Cholesky from libMyLib.a(Cholesky.o) not allowed in slidable image. Use '-read_only_relocs suppress' to enable text relocs
So the answer is: compile with ICL 10.1, not 11.1. None of the Intel libs used by 10.1 contain references to $UNIX2003 routines.
Hope it helps somebody.
A
Ultimately, you're going to need to get Intel product support from Intel, but if you want to sell Mac software that actually works then you should probably just use the same toolchain as everyone else and forget about it.