How to handle concurrent QT versions

How to handle concurrent QT versions

[Alexander Asteroth]

Dear all,

since two month I didn't update my guix system now since I have a few
self compiled softwares that depend on QT@5.15 (qtbase, etc.) which I
need every day. Now version 6 of QT replaces 5 everywhere and whithout
updating to 6 I cannot update a lot of other packages.

How do you guys handle this situation? Or am I the only one facing this
problem.

Cheers,
Alex

Re: How to handle concurrent QT versions

[Andreas Enge]

Hello,

Am Tue, Feb 28, 2023 at 12:25:13PM +0100 schrieb Alexander Asteroth:
> since two month I didn't update my guix system now since I have a few
> self compiled softwares that depend on QT@5.15 (qtbase, etc.) which I
> need every day. Now version 6 of QT replaces 5 everywhere and whithout
> updating to 6 I cannot update a lot of other packages.

I would expect it to work out of the box. From what I see, the Qt5
libraries are called libQt5xxx.so. Supposedly the Qt6 libraries are
called differently (libQt6xxx.so?), so you should be able to install
both of them into the same profile.

Independently, software from Guix built with one or the other can be
installed at the same time: They will just point to different libraries
in the store, unless you also install the Qt libraries into your profile.

Andreas

Re: How to handle concurrent QT versions

[Alexander Asteroth]

Dear Andreas,

thanks for the reply. If I get you correctly the point you make:
> [...] unless you also install the Qt libraries into your profile.

is probably the cause of my problem. I did not build the softwares as
guix packages but simply made them compile (after some manual changes to
the code) in my current environment. If I now run a `guix package -u`
the libraries (from qtbase) get upgraded from 5.15.5 to 6.3.1 and the
program fails to run.

I guess I either need to make them into guix packages or let them run in
the old guix environment they were build in, right?

Bests,
Alex

On Tue, Feb 28 2023, 17:53:11, Andreas Enge <andreas@enge.fr> wrote:

> Hello,
>
> Am Tue, Feb 28, 2023 at 12:25:13PM +0100 schrieb Alexander Asteroth:
>> since two month I didn't update my guix system now since I have a few
>> self compiled softwares that depend on QT@5.15 (qtbase, etc.) which I
>> need every day. Now version 6 of QT replaces 5 everywhere and whithout
>> updating to 6 I cannot update a lot of other packages.
>
> I would expect it to work out of the box. From what I see, the Qt5
> libraries are called libQt5xxx.so. Supposedly the Qt6 libraries are
> called differently (libQt6xxx.so?), so you should be able to install
> both of them into the same profile.
>
> Independently, software from Guix built with one or the other can be
> installed at the same time: They will just point to different libraries
> in the store, unless you also install the Qt libraries into your profile.
>
> Andreas

Re: How to handle concurrent QT versions

[Felix Lechner via]

Hi Alexander,

On Wed, Mar 1, 2023 at 12:23 AM Alexander Asteroth
<alexander.asteroth@h-brs.de> wrote:
>
> I guess I either need to make them into guix packages or let them run in
> the old guix environment they were build in, right?

I believe you are right (but I am new here).

Happy hacking!

Kind regards
Felix Lechner

Re: How to handle concurrent QT versions

[Andreas Enge]

Am Wed, Mar 01, 2023 at 09:14:27AM +0100 schrieb Alexander Asteroth:
> guix packages but simply made them compile (after some manual changes to
> the code) in my current environment. If I now run a `guix package -u`
> the libraries (from qtbase) get upgraded from 5.15.5 to 6.3.1 and the
> program fails to run.

Then I suppose that your Qt5 libraries disappear, so that the programs will
not find them; and the newly installed Qt6 libraries will not be of help
(they have a different name and are thus considered, well, different).
To check, you can do "ldd name-of-my-executable", which shows you which
libraries needed by your binary are found or not. So the solution is
to not do a "guix package -u", or to do a
"guix package --do-not-upgrade qtbase qtxxx qtyyy ... -u"
(with a potentially long list of Qt packages in the middle).

It might be easier then to create a separate profile with a manifest only
for your Qt5 development, which you would then avoid to update.
It is something I have not done myself yet, so I will have to refer you
to the documentation.

Andreas

Re: How to handle concurrent QT versions

[Alexander Asteroth]

Then it will probably be as easy (an cleaner) to make the program into a
"real" guix package with all the correct dependencies and install this package.

Cheers,
Alex

On Thu, Mar 02 2023, 11:11:56, Andreas Enge <andreas@enge.fr> wrote:

> Am Wed, Mar 01, 2023 at 09:14:27AM +0100 schrieb Alexander Asteroth:
>> guix packages but simply made them compile (after some manual changes to
>> the code) in my current environment. If I now run a `guix package -u`
>> the libraries (from qtbase) get upgraded from 5.15.5 to 6.3.1 and the
>> program fails to run.
>
> Then I suppose that your Qt5 libraries disappear, so that the programs will
> not find them; and the newly installed Qt6 libraries will not be of help
> (they have a different name and are thus considered, well, different).
> To check, you can do "ldd name-of-my-executable", which shows you which
> libraries needed by your binary are found or not. So the solution is
> to not do a "guix package -u", or to do a
> "guix package --do-not-upgrade qtbase qtxxx qtyyy ... -u"
> (with a potentially long list of Qt packages in the middle).
>
> It might be easier then to create a separate profile with a manifest only
> for your Qt5 development, which you would then avoid to update.
> It is something I have not done myself yet, so I will have to refer you
> to the documentation.
>
> Andreas

Re: How to handle concurrent QT versions

[Andreas Enge]

Am Fri, Mar 03, 2023 at 09:47:42AM +0100 schrieb Alexander Asteroth:
> Then it will probably be as easy (an cleaner) to make the program into a
> "real" guix package with all the correct dependencies and install this package.

Indeed, good point, this could also be an interesting option.
And "--with-source" can be used for software that is being developed.

Andreas