Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 851195 - sys-devel/autoconf-archive-2021.02.19 - broken Qt5 detection using AX_HAVE_QT macro
Summary: sys-devel/autoconf-archive-2021.02.19 - broken Qt5 detection using AX_HAVE_QT...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: qtbindir
  Show dependency tree
 
Reported: 2022-06-11 10:15 UTC by Fab
Modified: 2022-08-03 18:19 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
error running latest upstream macro (config.log.error,2.31 KB, text/plain)
2022-06-13 18:02 UTC, Fab
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fab 2022-06-11 10:15:50 UTC
Hi,

On a stable up-to-date system, AX_HAVE_QT macro is unable to detect Qt5.
The macro is provided by sys-devel/autoconf-archive-2021.02.19 package.

When you use this macro from a configure script generated by autotools, the error reported when running ./configure is :

> checking for Qt... configure: line 20119: qmake: command not found
> no

This happens since this change¹ on gentoo. Everything was running fine before this change.

If you go to upstream repository, you can see that the macro was patched² to make openSUSE happy.

On gentoo, should ax_have_qt.m4 be patched ? Or should a bug be reported upstream ?

Thank you.

1. https://archives.gentoo.org/gentoo-dev/message/5f3681b5b28dabeb5339d44e9585d29f
2. http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff;h=3444eac4af4fd93458552efaffe9d2343e2fb993
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-06-11 10:19:26 UTC
Please give an example project we can look at this with. But this sounds a lot like it's actually to do with the Qt bindir changes (see news).
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-06-11 10:20:05 UTC
(In reply to Sam James from comment #1)
> Please give an example project we can look at this with. But this sounds a
> lot like it's actually to do with the Qt bindir changes (see news).

Oh, sorry, I get your point, it should know about our locations. Duh.
Comment 3 Ionen Wolkens gentoo-dev 2022-06-11 10:22:21 UTC
Given qmake5 is in PATH now, easiest would be s/qmake/qmake5/ and no need to worry about hardcoding paths or qmake-utils eclass.
Comment 4 Ionen Wolkens gentoo-dev 2022-06-11 10:27:23 UTC
(In reply to Ionen Wolkens from comment #3)
> Given qmake5 is in PATH now, easiest would be s/qmake/qmake5/ and no need to
> worry about hardcoding paths or qmake-utils eclass.
(also I did suggest on the qt6 PR that qt6 should get qmake6 there too, didn't last I checked)
Comment 5 Fab 2022-06-11 19:30:09 UTC
(In reply to Sam James from comment #2)
> (In reply to Sam James from comment #1)
> > Please give an example project we can look at this with. But this sounds a
> > lot like it's actually to do with the Qt bindir changes (see news).
> 
> Oh, sorry, I get your point, it should know about our locations. Duh.
Yes. I'm developing a software on gentoo, and I'm using this macro to detect and setup Qt.
Until now I haven't had to do any special stuff neither in my build system nor in an ebuild to make it work.

Today I searched packages in the portage tree to see how things work for other packages,
and I noticed that every ebuild/package I saw is doing some hacky things to make it work.

On sys-libs/gwenhywfar :
>
> 	use qt5 && myeconfargs+=(
> 		--with-qt5-moc="$(qt5_get_bindir)/moc"
> 		--with-qt5-qmake="$(qt5_get_bindir)/qmake"
> 	)
> 
>
--with-qt5-{moc,qmake} options are coming from an old-custom version¹ of this macro, and now the developers of this package must patch this old version to fix bugs².

On app-crypt/pinentry :
> src_configure() {
>       export QTLIB="$(qt5_get_libdir)"
> 
>       econf \
>            ...
>            MOC="$(qt5_get_bindir)"/moc \
>            ...
But... calling AX_HAVE_QT should just work. And it worked for me until now.
Developing a package on gentoo does not mean that every build is done by emerge.
Most of the time I'm doing the eternal configure-make on command line.

Since upstream macro was patched for openSUSE, and since qt6 is coming, would it be possible to fix this once for all and for everyone ?



1. https://github.com/aqbanking/gwenhywfar/commit/11b63e8a7e5f2dc949de3bec0983de0e0255c75b
2. https://github.com/aqbanking/gwenhywfar/commit/b953672c5f668c2ed3960607e6e25651a2cc98db
Comment 6 Ionen Wolkens gentoo-dev 2022-06-11 20:03:47 UTC
The difference is that qtchooser is not installed by default anymore and is intended for people that develop with qt directly rather than make ebuilds for it, so direct qmake doesn't get installed.

https://www.gentoo.org/support/news-items/2022-03-30-qt-5_15_3-bump.html

So in a way could actually say that this is not necessarily a bug (albeit checking qmake5/qmake6 may be useful), ebuilds should do their things, and developers install qtchooser.
Comment 7 Fab 2022-06-13 18:02:17 UTC
Created attachment 784652 [details]
error running latest upstream macro

I'm trying to use latest version of upstream ax_have_qt.m4 macro with AC_CHECK_PROGS patched like following : 

> AC_CHECK_PROGS(am_have_qt_qmexe,qmake qmake-qt6 qmake-qt5 qmake6 qmake5,[])

I thought this would work, but calling the macro failed.
The config.log error is attached.

As you can see in the attached file, the
>    QT_UIC=
>    QT_MOC=
>    QT_RCC=
>    QT_LRELEASE=
>    QT_LUPDATE=
exported variables are empty, because which does not find them in PATH.

In the qtcore ebuild¹, in install phase, we can find :
> qt5_symlink_binary_to_path qmake 5

A symlink is done for qmake, but not for others utilities.
This leads to the macro failure.

1. https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-qt/qtcore/qtcore-5.15.4-r2.ebuild#n104
Comment 8 Andreas Sturmlechner gentoo-dev 2022-06-14 07:34:59 UTC
(In reply to Fab from comment #7)
> A symlink is done for qmake, but not for others utilities.
> This leads to the macro failure.
> 
> 1.
> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-qt/qtcore/qtcore-5.15.4-
> r2.ebuild#n104
This is by design and mimics what is provided as "user facing" by Qt6.

I assume that revdeps could rely on this, so package should be fixed in a universal, non-Gentoo-specific way (taking into account '5' and 'qt5' prefixes or injecting one QTBINDIR path for all these tools, but the latter again relies on knowledge of having to do this in revdep packages).

Nevertheless, as has been told, if you develop with Qt and rely on unversioned links to these Qt binaries in PATH, dev-qt/qtchooser as a tool still works for you with direct control over the (main) version you want. In the past, Qt packages in Gentoo were using it as a means to switch the 'default' Qt implementation, and you as a developer would not have had control over when the switch from Qt4 to Qt5 happened, and had we gone forward with it, the switch to Qt6 as well.

Fixing assignee.
Comment 9 Andreas Sturmlechner gentoo-dev 2022-06-14 07:35:56 UTC
(In reply to Andreas Sturmlechner from comment #8)
> (In reply to Fab from comment #7)
> (taking into account '5' and 'qt5' prefixes...
*suffixes
Comment 10 Fab 2022-06-14 10:22:08 UTC
(In reply to Andreas Sturmlechner from comment #8)
> Nevertheless, as has been told, if you develop with Qt and rely on
> unversioned links to these Qt binaries in PATH, dev-qt/qtchooser as a tool
> still works for you with direct control over the (main) version you want.

The problem is that, I, as developer, do not need these tools.
As a developer, I'm using only the AX_HAVE_QT macro provided by the sys-devel/autoconf-archive gentoo package.
The macro needs these tools to check the Qt correct installation, I do not.
Comment 11 Andreas Sturmlechner gentoo-dev 2022-06-14 10:28:12 UTC
Yes. But you can still use dev-qt/qtchooser to resolve the situation for you *right now*.
Comment 12 Fab 2022-06-14 11:34:07 UTC
Yes, that's true, thank you, I understood it well.
This also means that I must add an *unneeded dependency* to my ebuild until this bug is resolved. Do you see why I'm unwilling ?

If half of the macros distributed by autoconf-archive package does not work on the system where they are installed, or require extras deps to run, then it is useless to provide such a package.

I did not opened this bug to bother any of you, and I do not ask you to fix this *right now*. I simply think this is a real problem, especially on a OS where you build everything from sources, and where often we are asked to report problems upstream.
Comment 13 Andreas Sturmlechner gentoo-dev 2022-06-14 11:37:37 UTC
(In reply to Fab from comment #12)
> Yes, that's true, thank you, I understood it well.
> This also means that I must add an *unneeded dependency* to my ebuild until
> this bug is resolved. Do you see why I'm unwilling ?
C'mon, it is half a meg of mostly symlinks you had unconditionally installed until 5.15.3 anyway.
Comment 14 Fab 2022-06-14 11:44:07 UTC
(In reply to Andreas Sturmlechner from comment #13)
> C'mon, it is half a meg of mostly symlinks you had unconditionally installed
> until 5.15.3 anyway.

That's not the problem, but okay. Let's go, let's start doing anything with dependencies in the portage tree.
Comment 15 Andreas Sturmlechner gentoo-dev 2022-06-14 11:45:45 UTC
Did you somehow skip over this?

(In reply to Andreas Sturmlechner from comment #8)
> I assume that revdeps could rely on this, so package should be fixed in a
> universal, non-Gentoo-specific way
I'm not talking you out of this bug.
Comment 16 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-06-14 11:51:55 UTC
asturm was pretty much just explaining why it's not a "qt@" problem and why it's a bug in the macros if anything. And that as a workaround, the dep on qtchooser isn't horrible for now, if you must. I think you've misinterpreted.

It is indeed an issue in the macros which should be fixed.
Comment 17 Davide Pesavento gentoo-dev 2022-06-14 20:12:06 UTC
(In reply to Andreas Sturmlechner from comment #8)
> I assume that revdeps could rely on this, so package should be fixed in a
> universal, non-Gentoo-specific way (taking into account '5' and 'qt5'
> prefixes

+1