[Solved] Bunnyhole? Building Qt 5.3.2 for arm920t on Ubuntu 14.04...
-
Nope, the mangled va_list warning prevents compile of my application:
In file included from /opt/QT-arm/include/QtCore/qobject.h:49:0,
from /opt/QT-arm/include/QtWidgets/qwidget.h:46,
from /opt/QT-arm/include/QtWidgets/qmainwindow.h:45,
from /opt/QT-arm/include/QtWidgets/QMainWindow:1,
from ../readerpane.h:4,
from ../main.cpp:1:
/opt/QT-arm/include/QtCore/qstring.h:305:14: note: the mangling of 'va_list' has changed in GCC 4.4 -
Hi and welcome to devnet,
What board are you targeting ? What version of gcc are you using for your cross-compiler ?
Since you're cross-compiling, you also need to provide the dependencies for the correct architecture. You can take a look at the Raspberry Pi wiki page for inspiration
Hope it helps
-
The system is an iBase IPPC from this family
http://www.ibase-usa.com/productView.aspx?id=51The chip is Samsung S3C2440A-40 (arm920T)
The Linux build is
Linux sk100 2.6.21.5-cfs-v19-g3af17ce6-dirty #1
Wed Sep 17 17 :22:14 CST 2014 armv5tejl GNU/LinuxThey (iBase) build with arm-2011.03-41-arm-none-linux-gnueabi.bin
I obtained wget https://sourcery.mentor.com/sgpp/lite/arm/portal/package8739/public/arm-none-linux-gnueabi/arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2The compiler info is:
jandle@jca-VirtualBox-U32:/opt/CodeSourcery/bin$ arm-none-linux-gnueabi-g++ -v
Using built-in specs.
COLLECT_GCC=arm-none-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/opt/CodeSourcery/bin/../libexec/gcc/arm-none-linux-gnueabi/4.5.2/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with: /scratch/janisjo/arm-linux-lite/src/gcc-4.5-2011.03/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs --with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps: -fverbose-asm} %{funwind-tables|fno-unwind-tables|mabi=|ffreestanding|nostdlib:;:-funwind-tables} -D__CS_SOURCERYGXX_MAJ__=2011 -D__CS_SOURCERYGXX_MIN__=3 -D__CS_SOURCERYGXX_REV__=41 %{O2:%{!fno-remove-local-statics: -fremove-local-statics}} %{O:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --with-pkgversion='Sourcery G++ Lite 2011.03-41' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/janisjo/arm-linux-lite/install/arm-none-linux-gnueabi/libc --with-gmp=/scratch/janisjo/arm-linux-lite/obj/host-libs-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-mpfr=/scratch/janisjo/arm-linux-lite/obj/host-libs-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-mpc=/scratch/janisjo/arm-linux-lite/obj/host-libs-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-ppl=/scratch/janisjo/arm-linux-lite/obj/host-libs-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-cloog=/scratch/janisjo/arm-linux-lite/obj/host-libs-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-libelf=/scratch/janisjo/arm-linux-lite/obj/host-libs-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/janisjo/arm-linux-lite/install/arm-none-linux-gnueabi/bin --with-build-time-tools=/scratch/janisjo/arm-linux-lite/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41)I was able to build Qt 5.3.2 ignoring the va_list error message.
My understanding of name mangling (from back in 1990's when I did C++/FORTRAN mixed code) is that if the compiler I use to build the Qt kit is the same as the compiler I use to build the rest of the app, the dynamic libraries and applications should play well together.
If there is an issue anywhere it might be Qt Creator
Qt Creator 3.2.1 (opensource)
Based on Qt 5.3.2 (GCC 4.6.1, 32 bit)
Built on Sep 12 2014 at 15:42:24and Ubuntu 14.04's gcc package (4.8)?
jandle@jca-VirtualBox-U32:/opt/CodeSourcery/bin$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)If there is not a specific tool clash then I guess next I need to look at include paths since I have i386-Ubuntu Qt and arm-Linux Qt on the VM.
If it is a tool clash, then I need suggestions on a Qt 5 cross compile system compatible with the board manufacturer's Linux image based on arm-2011.03-41-arm-none-linux-gnueabi.bin
If it is not a tool clash but details of path variables, etc., then I would benefit from a few simple rules that I should have followed.
I am also at a point where i have much more important things to do than (re)learn deep details. I could justify "buying" a suitable binary for Qt if the cost to put a proper package together were justifiable.
-
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 ?
