@sneubert Thanks :)

Hi,

Absolutely, in the same creator session I can toggle between toolchains, Desktop is fine, but Raspberry Pi is giving the aforementioned problem.

This is my setup.

Build settings:

PATH: /home/ubuntuvm/raspi/qt5/bin:/home/ubuntuvm/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/bin

Kit:

Device:

Qt Versions:

Compilers:

Compiler Path (C & C++):
/home/ubuntuvm/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/bin/gcc

Debuggers:

Qbs:

The thing is, it seems to be looking at the libm.so.6 of your machine and not the one from the sysroot.

@SGaist Ahh, okay I see it.

Clone Build Config -> Delete Build Steps -> add Custom Process Step

Thanks for the inspiration!

@Tranquil
I don't know how you read your text-file. But if it is for example with QTextStream, you coulc read line by line, call QString QString::simplified() const on it. that removes all leading and trailing whitespaces and reduces al other whitespaces to a simple single space. That should include tab and multiple spaces.

Than QString::splitRef(QChar::Space); on it and you have a vector of all your entries (in StringRef format) -> convert it to your container.

@Saman19 said in Qt on MarsBoard, Cross compile error, Socket can fd:

Note: QtSerialBus: Newer kernel needed for flexible data-rate frame support (canfd_frame).

It does not seem to me a problem but an informative note.

If you do not use CAN, check:

Is Kernel Network CAN enabled? Something like: Networking support ---> <M> CAN bus subsystem support ---> --- CAN bus subsystem support <M> Raw CAN Protocol (raw access with CAN-ID filtering) <M> Broadcast Manager CAN Protocol (with content filtering) CAN Device Drivers ---> <M> Virtual Local CAN Interface (vcan) <M> Platform CAN drivers with Netlink support

Mandatory, because under the kernel is the SocketCAN that handles this.

Install the can-utils package

It is necessary to include / install QtSerialPort, not for CAN but for ModBus that is part of QtSerialBus.

Cleiton Bueno

Blog | Linkedin | B2Open

I have found a solution here.
Looks like Ubuntu couldn't run 32bit binary, but it's working now.

I have checked the source code of the qmakeevaluator and the changes are present in version 5.9.1, still it does not recognize the platform. Even if I try to hardcode to the qmake evaluator the following:

vars[ProKey("QMAKE_TARGET.arch")] = ProString("x86");

It does not change a thing, still tries to link qmake to x64.

Hi ! I have the same problem. The QT included in the last IMG doesn't include a Qmake file. So when I compile like you, it give the same error cause we need to interface with the supplied proprietary libs in /opt I think.
On the Raspberry Pi, we need to interface with the VC libs in opt/ to correctly initialise with hardware acceleration, but VC libs are only for the Broadcom chipset on the Pi. On my NanoPI, it is a S5P4418, with a Nexell backend. Maybe we have to do the same with the Nexell libs included on the IMG ? I have a Fire2A and a S2, not sure you have the same configuration as me.
Qt recognize EGL and OpenGLES 2 but can't seem to open a display without these libs.

@Sumit Should be possible, but I never used Bitbake

I haven't played with that system recently but AFAIR, you should be able to build the sysroot for your system on your desktop machine. Then you could use scp to copy the bits you need over to your device.

Doesn't your system provide a possibility to start from another device like a SD card or even a nfs ?

I was able to fix the problem by adding this to the qmake.conf file for the device:

QMAKE_INCDIR_QT += $$[QT_INSTALL_HEADERS]

I can only second what @ambershark says.
Using a virtual machine is far less pain than what you are trying.

@rickY79 Any of those versions should work if you have the tool chain

@micland Yes, you are right. I was somehow lost. I needed to have qmake compiled for x86_64, but what confused me was that this binary was mixed together with other (ARM) binaries.

Just to know. After config stage, it is possible to change CC variable in Makefile and get cross compiled qmake in a few minutes. Thank you and Regards !

Hi,

It depends, the 5.7 branch will contain the current work for the next 5.7 release so if you need something that's not in 5.7.0 you should follow 5.7. Otherwise 5.7.0.

Note that 5.7.0 is almost out.

@olejl77 this is the article I'm actually following! But the gcc-linaro-arm-linux-gnueabihf-raspbian doens't support ICU:

https://github.com/raspberrypi/tools/issues/41

and I don't understand which compiler the Qt5 stuff had in mind when wrote the linux-rpi3-g++ mkspec file because the architecture and the compiler flags are not supported!

@Mark81 it's a compiler issue: https://github.com/raspberrypi/tools/issues/41

Here is the catch

you have to use arm-linux-gnueabihf-'' instead of arm-linux-gnueabihf.

@SGaist thanks for your help

Just saw something, why are you using sudo ? That's not a good idea when you are building anything.

Hi,

Isn't that the same question as you asked here ?

@zappy
Hello.

Have you looked at the bug report in the other thread you were following? Apparently there were some bug in the static building for Qt 5.5 and it's fixed in Qt 5.6.1 (https://bugreports.qt.io/browse/QTBUG-51071). So aside from upgrading, am at a loss ...

Do you provide glib ?

@DEEPAK-NATH I'm not the one with the problem...

@Wieland Yes, that seems a better idea, I'll do that, thanks for your help :)

Hi,

Are you also using g++4.9 to build Qt ?

I am no more using minibian and switched to jessie lite version.

Did you do that on your Desktop machine ?

Is splash screen fine ? Do you see any colour inversion ?
Is your display 24bit or 16bit ?

Your distro is fine, its from fido branch.

Hi and welcome to devnet,

Don't get me wrong but are you aware that you are comparing a Dual Core 2GHz (so 2 Core at 2GHz) with 4GB of RAM and a low power ARM processor at 700MHz with 512MB or RAM ? Not to mention the GPU power levels that are also pretty different.

The first thing I'd check is how much data you are trying to process and show and optimize that.

I never got around to solve this issue, so due to time constraints i reverted to compile natively on the Raspberry Pi.