Location of Qt libs on raspberry pi3

koahnig

Probably a really stupid question for all those familiar to linux. However, I am typically developing on Windows.

Finally I have managed to cross-compile Qt 5.9.2 for raspberry pi3 based on https://wiki.qt.io/RaspberryPi2EGLFS

The cross-compilation is done in a virtual box running ubuntu. Ihave followed the guidelines and also did at the end "make install".
I have setup Qt creator also in the virtual box and was able to compile the analog clock example code and transfer it to the raspberry pi. It also runs "hurray"

Since the configure holds prefix information "-prefix /usr/local/qt5pi" I expected to find all dynamic libraries somehow in that specified folder on rpi, but the only thing I have found is a folder called "examples/gui/analogclock" and the application analogclock there.

Where are the dynamic libraries from my cross-compilation?

SGaist

Hi,

From what I remember, the cross-compiled libraries went in /usr/local/qt5pi as for your RPi, the easiest to find out is to run ldd your_application_name on the target and you'll have the list of the linked libraries and their path.

koahnig

@SGaist

That is the ldd output from rpi.

	linux-vdso.so.1 (0x7ec6c000)
	/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f84000)
	libQt5Gui.so.5 => /usr/lib/arm-linux-gnueabihf/libQt5Gui.so.5 (0x76b44000)
	libQt5Core.so.5 => /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 (0x766e5000)
	libGLESv2.so.2 => /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 (0x766cb000)
	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x766a2000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x7655a000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x764db000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x764ae000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x7636f000)
	libharfbuzz.so.0 => /usr/lib/arm-linux-gnueabihf/libharfbuzz.so.0 (0x762d8000)
	libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x762b1000)
	libpng16.so.16 => /usr/lib/arm-linux-gnueabihf/libpng16.so.16 (0x76277000)
	/lib/ld-linux-armhf.so.3 (0x76f9a000)
	libicui18n.so.57 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.57 (0x76067000)
	libicuuc.so.57 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.57 (0x75efd000)
	libpcre16.so.3 => /usr/lib/arm-linux-gnueabihf/libpcre16.so.3 (0x75e8f000)
	libdouble-conversion.so.1 => /usr/lib/arm-linux-gnueabihf/libdouble-conversion.so.1 (0x75e6d000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x75e5a000)
	libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x75d52000)
	librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x75d3b000)
	libdrm.so.2 => /usr/lib/arm-linux-gnueabihf/libdrm.so.2 (0x75d1e000)
	libglapi.so.0 => /usr/lib/arm-linux-gnueabihf/libglapi.so.0 (0x75ce5000)
	libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x75c4a000)
	libgraphite2.so.3 => /usr/lib/arm-linux-gnueabihf/libgraphite2.so.3 (0x75c17000)
	libicudata.so.57 => /usr/lib/arm-linux-gnueabihf/libicudata.so.57 (0x7438a000)
	libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x74311000)

Obviously not the ones expected. I have checked the date of those libraries. They must have been installed through one of the steps given in the guidelines.

SGaist

Are you sure that they are not the one provided by the distribution you are using on the Pi ?

If you want to use the other ones, I would use rsync to copy them form the desktop machine in the same folder in the sysroot.

koahnig

@SGaist

You are completely right with your remark.
The prefix used in configure will only effect where your application will be copied, because you need always to give the password, if you have any.

I have rsync used to copy the freshly compiled Qt libs, but I struggle at the moment to find the right EGL libs. This part of the guidelines are not matching what I found on rpi.

SGaist

What trouble do you have with EGL ?

koahnig

@SGaist

First ao all my statement at the beginning that I have followed the guidelines is not absolutely correct. I did miss the end of the guidelines after section with "configure up to make install".

After discovering that the Qt libs are obviously not the ones which should be used I had found the section for updating the Qt libs with rsync as you also recommended.

Now I am stuck in section 14. [on RPi]

sudo mv /usr/lib/arm-linux-gnueabihf/libEGL.so.1.0.0 /usr/lib/arm-linux-gnueabihf/libEGL.so.1.0.0_backup
sudo mv /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0_backup
sudo ln -s /opt/vc/lib/libEGL.so /usr/lib/arm-linux-gnueabihf/libEGL.so.1.0.0
sudo ln -s /opt/vc/lib/libGLESv2.so /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0
sudo ln -s /opt/vc/lib/libbrcmEGL.so /opt/vc/lib/libEGL.so
sudo ln -s /opt/vc/lib/libbrcmGLESv2.so.2 /opt/vc/lib/libGLESv2.so

It does not match what I have found on my RPi. Only the first "mv" is possible, but already the next "mv"

sudo mv /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0_backup

is not possible because "/usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0" is not there.

The libraries on "/opt/vc/lib" are also different they feature a "_static". Therefore, I assume that they are static version and not the ones required.
A "find" run on the RPi did not show any other version.

The "funny" thing is that I was able to compile the analogclock example with a cross-compiled version of 5.9.2 and the obvious old/standard version of those libs. I guess the EGL did not work properly, because I could not show an image in the clock as a test.

The update to proper Qt dynamic libs with rsync created now more in coimpatibilities. The example does not work anymore.

koahnig

I guess that is the explanation for the problems. A reference link is given in the guidelines, but hard to see with the color scheme.

https://bugreports.qt.io/browse/QTBUG-62216

SGaist

Are you using the same Linux distribution on the RPi ?

koahnig

@SGaist

Yes, I am using "2018-11-13-raspbian-stretch-full" as found by following the download links.

Part of my problems are due to missing knowledge on linux and wrong sequence in letters.

I got the example analogclock back to work by basically running those commands (sudo ln -s ...) blindly.

However, the analogclock is not working properly. It is always started in full screen mode without anything left to stop the application. I plan to follow the comments given in the bug report. At the moment I got a feeling of entering the next struggle of a "windows boy" on linux.

koahnig

I have recompiled with adjusted settings as recommended (always a bit of interpretation required).

However, nothing changed. The analog example is shown full screen, even buttons are missing. Therefore a stop through Qt creator from my linux machine or a reboot of RPi required .
Still the same error return messages found in Qt creator output window

13:28:52: Starting /usr/local/qt5pi/examples/gui/analogclock/analogclock...
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).

No clue how to change that.

Pablo J. Rogina

@koahnig said in Location of Qt libs on raspberry pi3:

Finally I have managed to cross-compile Qt 5.9.2 for raspberry pi3 based on https://wiki.qt.io/RaspberryPi2EGLFS

If you did follow all the steps exactly, the location of Qt libraries in RPi is stated in step #6

/usr/local/qt5pi

and given you moved the cross-compiled libraries to the device given in step #11

rsync -avz qt5pi pi@raspberrypi.local:/usr/local

koahnig

@Pablo-J.-Rogina

I did follow and the freshly recompiled have been rsynced. However,it did not change the error message as given in my prior post.

Pablo J. Rogina

@koahnig sorry I missed the issue regarding QT_QPA_EGLFS_PHYSICAL_* message. You may want to take a look at this post