Use two QT5.x versions in parallel

[ben80]

I need to run two programs on the raspberry pi 2, eaching using a different version of QT5.
Which options do i have, to tell each program which libs to use? If any.

My setup:

• program #1: Python 3.7.10, Pyside2 installed via debian buster apt-get, this is currently QT5.11.3
• program #2: C++ program, crosscompiled following this tutorial (Link), QT5.15.2

Used QT functions:

• program #1: uses QCoreApplication, QTimer, QThread but no graphics
• program #2: C++ with QML using graphics via OpenGL ES on the raspberry

My questions:

1. Is it alright to have this setup or ist this a mess and should be avoided?
2. If it's alright, which options do I have, to tell each program which libs to use?

Options i have considered so far:

1. Export LD_LIBRARY_PATH before starting program #1 (path1) and also before #2 (path2).
2. Export LD_LIBRARY_PATH only for program #1 (Python) and for program #2 add /usr/local/qtpi_5.15.2/lib to /etc/ld.so.conf.d/00-qt5pi.conf and run ldconfig
3. Default /etc/ld.so.conf.d/ and ldconfig to the lib path for program #1 (Python) and somehow "hard code" the path for program #2 into its executable (How?)

Option 3) seems the most convenient.

Thanks for your help
Ben

[sierdzio]

I'd go with option 1 as the simplest (well depending whether this is for testing or production kind of use). But if you want option 3, it is OK as well.

somehow "hard code" the path for program #2 into its executable (How?)

You can use rpath for that. Or statically compile Qt and your app.

Is it alright to have this setup or ist this a mess and should be avoided?

It'd say it would be preferable to have only one Qt version here. But it's not a big deal I guess.

[ben80]

@sierdzio
Thanks a lot.

If I use rpath, then I still use the crosscompiled shared library, but I store in the executable where the shared libs are located, right?

If I statically link my app, then the libs are included in the executable and I don't need the shared lib anymore, right?

Would you be kind to give me guidance for the rpath option?

[SGaist]

Hi,

How did you install your cross-compiled Qt 5.15 ?

It should not class with your system provided Qt unless you put it in a patch searched by the library loader and found before the "official version".

[sierdzio]

@ben80 said in Use two QT5.x versions in parallel:

@sierdzio
Thanks a lot.

If I use rpath, then I still use the crosscompiled shared library, but I store in the executable where the shared libs are located, right?

Yes you use cross-compiled stuff.

No, you can put executable where you want it to be - but during compilation you need to specify rpath to point (relative!) to where Qt libs are.

See: QMAKE_RPATHDIR

If I statically link my app, then the libs are included in the executable and I don't need the shared lib anymore, right?

Yes. You may still need to ship the plugins in the same dir as executable.

And of course, you need to be careful about license when you link statically, it often means GPL will kick in.

[ben80]

@sierdzio said in Use two QT5.x versions in parallel:

but during compilation you need to specify rpath to point (relative!) to where Qt libs are.
See: QMAKE_RPATHDIR

Ok, I call qmake now as follows and I could run both programs on the raspberry in parallel as i wanted to. Thanks!

qmake QMAKE_RPATHDIR+=/usr/local/qtpi_5.15.2/lib

I will now crosscompile all other qt5 modules, and hope that works as well.

@SGaist said in Use two QT5.x versions in parallel:

How did you install your cross-compiled Qt 5.15 ?
It should not class with your system provided Qt unless you put it in a patch searched by the library loader and found before the "official version".

Good question, i am not sure if i understand it correctly. Do you mean this?
I run ./configure, then make and make install
Then i run rsync -avz qtpi_5.15.2 pi@192.168.1.31:/usr/local as normal user from my linux host pc

[jeremy_k]

@ben80 said in Use two QT5.x versions in parallel:

I need to run two programs on the raspberry pi 2, eaching using a different version of QT5.
Which options do i have, to tell each program which libs to use? If any.

My setup:

• program #1: Python 3.7.10, Pyside2 installed via debian buster apt-get, this is currently QT5.11.3
• program #2: C++ program, crosscompiled following this tutorial (Link), QT5.15.2

Used QT functions:

• program #1: uses QCoreApplication, QTimer, QThread but no graphics
• program #2: C++ with QML using graphics via OpenGL ES on the raspberry

My questions:

1. Is it alright to have this setup or ist this a mess and should be avoided?

What's the reason for using different versions of Qt 5? Going down this route opens up a class of problems involving incompatible intermingling.

2. If it's alright, which options do I have, to tell each program which libs to use?

Options i have considered so far:

1. Export LD_LIBRARY_PATH before starting program #1 (path1) and also before #2 (path2).

Avoid LD_LIBRARY_PATH, or any environment variable that can impact the function of a typical program. It's common to pass the same environment to child processes, meaning they will also use the same altered view of available libraries. If there's a sequence where program #1 invokes program #2 or another Qt application, even indirectly, the wrong set of libraries may be used. The same goes for any other libraries that may be stored in the same directory.

2. Export LD_LIBRARY_PATH only for program #1 (Python) and for program #2 add /usr/local/qtpi_5.15.2/lib to /etc/ld.so.conf.d/00-qt5pi.conf and run ldconfig
3. Default /etc/ld.so.conf.d/ and ldconfig to the lib path for program #1 (Python) and somehow "hard code" the path for program #2 into its executable (How?)

If Qt 5.11 is found before 5.15, the C++ program linked against 5.15 will ignore it due to semantic versioning. It shouldn't be necessary to hard code a path.

Option 4)
Have you looked into using a virtualenv for the python program? Apt-get won't install into it, but pip will. This encapsulates the library path mangling, although the same environment pollution problem exists for child processes.

[ben80]

@jeremy_k said in Use two QT5.x versions in parallel:

What's the reason for using different versions of Qt 5? Going down this route opens up a class of problems involving incompatible intermingling.

@jeremy_k said in Use two QT5.x versions in parallel:

Option 4)
Have you looked into using a virtualenv for the python program? Apt-get won't install into it, but pip will. This encapsulates the library path mangling, although the same environment pollution problem exists for child processes.

It seems like there is so much that i can do wrong here. I am running this raspberry only at my home, so i am not distributing it. As long as i have a working solution (not too messy) it's ok for me.
I cannot use pip on the raspberry, since there are no ARM packages for PySide2 provided. Therefore i am using apt-get. I am also using a pyenv virtualenv, but i need to copy the site-package files manually. Not nice, but it works.

[jeremy_k]

@ben80 said in Use two QT5.x versions in parallel:

@jeremy_k said in Use two QT5.x versions in parallel:

What's the reason for using different versions of Qt 5? Going down this route opens up a class of problems involving incompatible intermingling.

@jeremy_k said in Use two QT5.x versions in parallel:

Option 4)
Have you looked into using a virtualenv for the python program? Apt-get won't install into it, but pip will. This encapsulates the library path mangling, although the same environment pollution problem exists for child processes.

It seems like there is so much that i can do wrong here. I am running this raspberry only at my home, so i am not distributing it. As long as i have a working solution (not too messy) it's ok for me.

That's the best version of an unfortunate scenario. If you're careful about not executing other programs, the environment variable issue is manageable. Python modules that use external commands to discover bits of system configuration appears to be common. For example, https://github.com/pyinstaller/pyinstaller/issues/4657. QDesktopServices::openUrl() failing to work is another one to watch for.

I cannot use pip on the raspberry, since there are no ARM packages for PySide2 provided. Therefore i am using apt-get. I am also using a pyenv virtualenv, but i need to copy the site-package files manually. Not nice, but it works.

It might be reasonable to tell apt-get to install into the venv directory as an alternative root. For dpkg, the option appears to be --root=<alternative root>.