[Solved] Bunnyhole? Building Qt 5.3.2 for arm920t on Ubuntu 14.04...
-
You also have the possibility to check the "QtEnterpriseEmbedded":http://doc.qt.digia.com/QtEnterpriseEmbedded/index.html offering from Digia where you might be get started more easily however, discuss with them the support of your target before.
Anyway, AFAIK, you cross-compiler should build Qt without problem. For the OpenGL part, are you sure your device provides hardware for that ?
For the Qt Creator part, how did you setup your arm Qt Version ?
-
So, I know I don't have openGL support built in and I know I don't want to go down a mesa bunnyhole for what will be a pretty static GUI. Attempting to compilr with -qpa linuxfb. It passes the system sanity check and I know I have a working /dev/fb0.
I have seen other people use this compiler version, so it is not the problem. Then again I know they used it because I google'd my problem and found theirs. The va_list issue is a GCC issue widely commented on. Apparently it is 100% nuisance reporting and I could go into each makefile and attempt to put in warning suppression.
QtCreater (Ubuntu native) was installed from qt-opensource-linux-x86-5.3.2.run It runs QtWidgets code in Ubuntu so, OK.
I did find a lot of clashed paths from having both native and cross Qt without proper build variables, but I am also inconsistently getting completed builds as well. Apparently I cannot properly clean between builds :(
But, before I go much further down this bunny hole, can I make a Qt target set of .so's for a QtWidget app with QtNetwork that will fit this machine's 128MB flash (with the business end of the applications and a smallish SQL database, etc., etc. ...) Certainly the debug .co's of a full build won't fit.
-
Looks like a successful build with all features, so I'll iterate removing features as needed later... release builds look like around 20-25MB flash.
QtCreator accepts the kit and makes a binary.
sftp it and the libs... won't run.
[root@sk100 /etc]# cd /home/isaw
[root@sk100 isaw]# ls
iBaseQtWidget
libQt5Sensorsarm.so.5
libQt5Corearm.so.5
libQt5SerialPortarm.so.5
libQt5Declarativearm.so.5
libQt5Sqlarm.so.5
libQt5Guiarm.so.5
libQt5Widgetsarm.so.5
libQt5MultimediaWidgetsarm.so.5
libQt5Multimediaarm.so.5
libQt5Positioningarm.so.5
[root@sk100 isaw]echo $PATH
/usr/bin:/bin:/home/isaw
[root@sk100 isaw]# ./iBaseQtWidgetlibs are there and in the path...
./iBaseQtWidget: error while loading shared libraries: libQt5Widgetsarm.so.5: cannot open shared object file: No such file or directory
-
OK, after resorting to a full build and then
export LD_LIBRARY_PATH=/home/isaw/Qt/lib:$LD_LIBRARY_PATHThe application finds its library depenencies.
Now I get errors from iconv and linuxfb.
Am I supposed to have brought font files over?
Am I supposed to have made a linuxfb plugin?[root@sk100 isaw]# ./iBaseQtWidget
QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed
QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed
This application failed to start because it could not find or load the Qt platform plugin "linuxfb".Reinstalling the application may fix this problem. Aborted
-
issues up to here solved following http://qt-project.org/forums/viewthread/46640/ and looking at where Qt thinks I was putting files.
How do I mark this "solved"?
-
It might also be easier to install the libs properly on your target so if you write several applications you don't have to play with LD_LIBARY_PATH each time.
-
Ah, you presuppose that I know what "properly" is.
I started Linux embedded in June when a vendor for an RTU failed me in the field... I have Ubuntu desktop, two units from MOXA and the one from iBase. Let me just say there are neither hobgoblins nor little minds given the lack of consistency!Good news is my GUI is doing the most urgent things and - as soon as I convert incoming UDP datagrams to registers - I can demo it and get this into development by one of my engineers. They are already working on cleaning up the MODBUS code, adding other protocols, etc...
Bad news is (will post a separate topic unless you want it here) I have font scaling issues in the embedded system. Probably an easy fix if I knew what I was doing.
After that I need to generate some XY line graphs... There must be a widget for that!
-
Yes, I did and indeed four months in the rush is a bit short to get used to the embedded world.
For the fonts, check that you have the fonts installed on your device
For graphs, take a look at Qwt and should be easy to build for your target (it's essentially qmake, make. Just take a look a the configuration pri file, so you don't build things you won't use)
-
well, four months of embedded Linux (or any Linux). From the 4004 through i86 (Beck) systems, 6800 family, various PICs and TMS320, I have done embedded in one way or another since the early 80's. I have Linux based RTU using GPRS in the field and still cannot use GDB.
The font (Deja Vu Serif (embedded)) is being found - or rather I got an error then moved fonts to the folder it wanted to look for them in. The screen fonts look like the font I chose - just scaled. I even see the first rendering of numbers in my QLineEdit boxes being one size and the next time they are written they are scaled to fit. There must be a setting somewhere about scaled vs. absolute that I am missing and a size value that embedded is not obtaining.
I am playing with QCustomPlot right now and the examples do what I want on the target device - except Qt is not picking us the evdev associated with tslib. The vendor demos and config tools are so either a Qt setting or a path setting.
I am using QtCreator to build with selectable kits for Ubuntu or iBase. Slight nuisance that it wants to reset paths in QCustomPlot in the ui header auto-generated for the form, but I'll get through that soon enough.
-
Remote GDB ? Can be tricky indeed.
When starting your application are your giving it the input module it should load as parameter ?
