Hoping to have some Eclipse PDE guru's weigh in here in a problem I'm having trouble solving.
I am attempting export (via PDE UI) a feature that has two fragments included where both fragments target the same os (e.g., Linux) but have different architecture values (e.g., x86 and x86_64). Each fragment has their own copy of several .so library files, which were built on the either Linux x86 or Linux x86 64 bit. For example:
FragmentA (os=Linux,arch=x86)
lib1.so
lib2.so
lib3.so
FragmentB (os=Linux,arch=x86_64)
lib1.so
lib2.so
lib3.so
Exporting the hosting feature with using the corresponding delta pack to select either linux (gtk/x86) OR linux (gtk/x86_64), the export works as expected. However, when I select BOTH platforms, the export fails with the following message:
Processing inclusion from feature com.sample.feature:
Bundle com.sample.linux.x86_64_1.0.0.qualifier failed to resolve.:
Unsatisfied native code filter:
lib1.so; lib2.so; lib3.so; processor=x86_64; osname=linux.
Why can't I export both fragments together? I also have a Win32 x86 fragment that I can export with the linux X86 feature but instead of having .so files, it has .dll files with the same file titles (e.g., lib1.dll, lib2.dll, lib3.dll).
Could having .so library files named the same in the two Linux-based fragments cause this issue?
Any help would be much appreciated as this is a critical block to our build process (both manually via the UI and headlessly).
Related
We are trying to cross compile the wxGTK (2.8.12) to our ARMv5 embedded device.
Since RAM space is limited to 64MB, we thought of not using X11.
So, we have built DirectFB and GTK+ (with gdktarget as directfb and without x).
Now, we are trying to build wxGTK with GTK+. But it seems like, it need X11 header files. Got following compiler errors:
./src/unix/utilsx11.cpp:31:22: warning: X11/Xlib.h: No such file or directory
./src/unix/utilsx11.cpp:33:23: warning: X11/Xutil.h: No such file or directory
./src/unix/utilsx11.cpp:40:22: warning: gdk/gdkx.h: No such file or directory
./src/unix/utilsx11.cpp:44: error: ‘Atom’ does not name a typeenter code here
....
Is it possible to build wxGTK with GTK+ (directfb) but without X?
Thanks,
Hari
wxGTK requires GTK+ and, while GTK+ can use different backends, notably Wayland, it's unlikely to be available on your device.
You could try building wxDirectFB instead, but wxDFB is a very alpha-quality port which hasn't been in use since quite some time, so you should be ready to do some work on it yourself in order to implement the missing parts (there will definitely be at least some).
There is a minimalist GNOME implementation based on the GTK+. It is based on the X11 and GTK+. It can be build using OpenEmbedded or probably downloaded as prebuilt WM.
Now looking at it I think you can try GNOME Embedded with wxGTK.
i am using Qt5.7.1 on debian jessie linux virtual machine and deploy my application on the iMx6 processor, also running Qt5.7.1 and debian jessie.
I compiled the QtVirtualkeyboard project to add all languages that Qt supports.
First i compiled it for the PC linux and after for the iMx6.
I copied the new build plugin into the iMx6 Qt install plugin path and the other files required.
So on PC side the "basic" example project shows all languages with no issue.
Running the same example project on iMx6, i get almost all languages except those:
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/ja_JP/japaneseInputMethod:1:57: JapaneseInputMethod is not a type
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/ko_KR/hangulInputMethod:1:57: HangulInputMethod is not a type
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/zh_CN/pinyinInputMethod:1:57: PinyinInputMethod is not a type
qml: Qt.createQmlObject(): failed to create object:
qrc:/QtQuick/VirtualKeyboard/content/layouts/zh_TW/tcInputMethod:1:57: TCInputMethod is not a type
Did i miss to copy a source file for those languages or something?
If yes which files and where should they be copied to?
So i did made it to work.The problem is that QtVirtualkeyboard uses thirdparty libraries and it cannot find it.
To solve the proble you must also compile all QtVirtualkeyboard thirdparty libraries and copy it to your ARM CPU like iMx6.
Example for simple chinese:
cd /home/yourname/Qt5.9.1/5.9.1/Src/qtvirtualkeyboard/src/virtualkeyboard/3rdparty/pinyin
qmake
make
Copy the .dat library for pinyin (dict_pinyin.dat) to directory like
/usr/local/qt5.9.1/qtvirtualkeyboard/pinyin
Now QtVirtualkeyboard should find the simple chinese dictonary. This should be done for japonese and traditional chinese and hundspell as well if you use them.
I have a project using MonoMac in Xamarin Studio. I'm using [DllImport ("rlimit")] to access a .dylib file. However, even though I have mapped rlimit to rlimit.dylib, a DllNotFoundException is still thrown.
The .dylib files are in the project and should be accessible, however they cannot be found.
I'm guessing that the files are either in the wrong place, or they aren't being detected for some reason.
You need to put the dylib anywhere mono can find it.
You can find out where mono looks for native libraries by doing this:
export MONO_LOG_LEVEL=debug
export MONO_LOG_MASK=dll
mono yourprogram.exe
and verbose lookup output will be printed to the terminal. On my system mono looks first in the directory where the executable is, so putting the dylib there is probably the easiest. Then mono asks the system to find the dylib (by trying to open it without a path). The system typically looks in /usr/lib and maybe a few other places (this is of course system-dependent), but in any case you can add a path for the system to look in by setting LD_LIBRARY_PATH to that path. In this case you'll do this:
export LD_LIBRARY_PATH=/path/to/dylib:$LD_LIBRARY_PATH
mono yourprogram.exe
Note that you do not need the .dllmap, mono will automatically append the appropiate suffix depending on the platform (.dylib on Mac, .so on Linux and .dll on Windows).
I am working on a project that is using Leopardboard DM368 interfacing with LI-M024DUAL camera board for stereo vision. The camera uses Aptina's MT09M024 as its image sensor.
After spending a lot of time on the web searching for appropriate drivers I asked the OEM to provide me some support. They provided me with the driver source files. The problem is I am not able to include them to the kernel.
I also looked up for the method to build modules and am fairly comfortable with it. But with the current driver I have a bunch of *.c files that use non-existent header files (I am not able to find these linux header files in the /linux directory).
Now my question is if I have the source code for an image sensor driver and want to build it, what is the general procedure followed for the same.
Any help in this regard would be welcome.
-Kartik
There are two ways to build you module:
1. Statically linking to kernel image (inbuilt)
2. Creating dynamically loadable Modules
Statically linking to kernel image (inbuilt)
For this you must find a appropriate place in kernel folder (somewhere in drivers/) to copy your .c files. copy them there. Edit Kconfig and Makefiles refering to other kernel drivers. and enable the support using menuconfig. Compile.
Creating dynamically loadable Modules
You can built without copying them to Kernel source. Just create a Makefile and place rules in Makefile to compile your module. Here you must link your module to your kernel by providing the kernel source path.
For more google should help.
We bundle the Java 6 JRE with our application installer so that it can be run on any machine, but this makes the application a little bit heavier. So we are planning to reduce the size of the JRE. If anyone has done this sort of task, can you please provide guidance to move forward with this?
Look at the README file in the JRE directory. The 'Optional Files and Directories' section lists a number of files that can be removed from the Oracle/Sun JRE if you are packaging it with your application.
I use an Ant buildfile to copy the JRE from the system install location to the package directory when creating an installation. Put the list of files you want excluded in a separate file and use the 'excludesfile' attribute to load this list:
<copy todir="${deployed_jre_dir}">
<fileset dir="${system_jre_dir}" excludesfile="jre_excludes.properties"
</copy>
Sample jre_excludes.properties file:
# per the README from the JRE, these files are for the browser plugin and are not needed otherwise
#bin/javaw.exe
bin/javaws.exe
bin/javacpl.exe
bin/jucheck.exe
bin/jusched.exe
bin/wsdetect.dll
bin/NPJPI*.dll
bin/NPJava*
bin/NPOJI610.dll
bin/RegUtils.dll
bin/axbridge.dll
bin/deploy.dll
bin/jpicom.dll
bin/javacpl.cpl
bin/jpiexp.dll
bin/jpinscp.dll
bin/jpioji.dll
bin/jpishare.dll
lib/deploy.jar
lib/plugin.jar
lib/javaws.jar
lib/javaws/messages*
lib/javaws/miniSplash.jpg
bin/new_plugin**
bin/jureg*
bin/ssv*
bin/jqs*
bin/jp2*
lib/deploy/**/*
# if you do not need any RMI stuff
# wildcard to catch .exe files on Windows
# note rmi.dll is not excluded, which is needed by jconsole; add rmi.dll if you do not need jsonsole
bin/jbroker*
bin/java-rmi*
bin/rmid*
bin/rmiregistry*
bin/tnameserv*
bin/orbd*
bin/servertool*
# do not include QuickTime
# this will be in the jre dir for machines that have QT installed
lib/ext/QTJava.zip
Some update info: since java 8 there is an official Oracle tool called jrecreate for creating of small embedded JRE packages.
For my Java 8 Update 144 desktop application I exclude the 2 big Java FX files:
bin/jfxwebkit.dll // ~34 MB unpacked
lib/ext/jfxrt.jar // ~17 MB unpacked
The zipped jre is 49 MB instead of 66 MB.
For me this is an acceptable tradeoff between reduced size and added build complexity (and potential bugs).
You're trying to reduce a standard JRE's size? Don't do that. You can choose to bundle an alternative JRE which might be smaller. A list can be found on this Wikipedia page. As always, beware of compatibility issues and test your application thoroughly.
An other, and safer, way is to just require an installation of a JRE on the target machine.
You can use jlink tool to post-process JDK and create a smaller image by keeping only a specified set of JMPS modules and debug information. This is a common practice right now as we are using more containerized environments.