[Solved] Bunnyhole? Building Qt 5.3.2 for arm920t on Ubuntu 14.04...



  • Goal: Qt application on arm-linux 2.6 with GUI + Widgets + UDP + TCP.

    I wrote a trivial case in VS2010 to convince myself it could work and that I could learn it in the little time available.
    ... convinced myself I could make the time.

    I migrated it to Ubuntu-64 under VirtualBox... no issues.
    I added arm-none-linux-gnueabi-xxx and loaded Qt-everywhere 5.3.2 source.
    I then hit a wall creating arm-Qt...

    I assumed it was 32/64 bit mismatch, so I made a new VM with Ubuntu32...
    Test app again runs under Ubuntu 32 bit on the PC.

    Loaded (again) Qt source and spent most of the day fighting with configure...

    ./configure -developer-build -prefix /opt/QT-arm -debug -opensource -confirm-license -shared -no-largefile -qtnamespace QT -gui -widgets -plugin-sql-mysql -continue -xplatform arm-none-linux-gnueabi-g++ -platform linux-g++ -device linux-arm920T-g++ -device-option CROSS_COMPILE=/opt/CodeSourcery/bin/arm-none-linux-gnueabi- -no-compile-examples -silent -no-warnings-are-errors -no-pch -no-dbus -no-sse2 -no-cups -no-iconv -no-nis

    dbus ... I just could not get it to work, so I was lucky it isn't needed.
    -eglfs -opengl es2 ... thought I needed them because I got dependency warnings about openGL on Widgets.
    I probably had eglfs without opengl es2...

    With this configuration,
    make -k -s -Wno-psabi (which is NOT suppressing the va_list warning from qstrings.h as advertised)
    I think it is building (in the middle of a rebuild after a clean of dbus stragglers)

    When I try to ad them:
    The OpenGL ES 2.0 functionality test failed!
    You might need to modify the include and library search paths by editing
    QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 and QMAKE_LIBS_OPENGL_ES2 in
    /home/jandle/Documents/Code/QT-arm/qtbase/mkspecs/devices/linux-arm920T-g++.

    So, now that I have crawled back out of the bunny-hole, if all I am doing are 2D controls and line charts for an HMI, do I care about openGL support?

    If I do care, it looks like a very long bunny-hole of recursively installing tools to build tools to create this kit so I can develop my app. Is there any chance of simplifying this process?



  • 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

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748


  • Lifetime Qt Champion

    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=51

    The 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/Linux

    They (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.bz2

    The 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:24

    and 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.


  • Lifetime Qt Champion

    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]# ./iBaseQtWidget

    libs 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_PATH

    The 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"?


  • Lifetime Qt Champion

    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!


  • Lifetime Qt Champion

    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.


  • Lifetime Qt Champion

    Remote GDB ? Can be tricky indeed.

    When starting your application are your giving it the input module it should load as parameter ?


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.