Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
Hi Dmitry and Lisandro,
thanks for working on this.
On Mon, Feb 20, 2023 at 10:49:52AM +0300, Dmitry Shachnev wrote:
> On Sun, Feb 19, 2023 at 08:20:43PM -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > On Sun, 19 Feb 2023 at 16:59, Dmitry Shachnev wrote:
> > > What are these paths?
> > >
> > > I think one that Helmut mentioned is the most important and should cover
> > > most
> > > cases.
> >
> > Paths to uic. moc et all.
>
> IIRC, uic and moc produce the same output on all architectures, so we do not
> need cross wrappers for them.
>
> So calling the native /usr/lib/qt6/bin/{uic,moc} should be absolutely fine.
I agree with all of that.
Lisandro also asked:
| sbuild -host arm64 -sAd unstable some_qt6_app.dsc a good way to test this?
I's --host rather than -host.
Do not pass -A. To simplify matters, cross builds are always assumed to
be arch-only.
Other than that, this should work.
Maybe you should check that qemu's binfmt integration is disabled.
Otherwise, you may be a successful build that only happened to work due
to using qemu. You can run "update-binfmts --disable" to disable all
binfmts and reenable them afterwards.
Helmut
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
El lun, 20 de feb. de 2023 04:49, Dmitry Shachnev
escribió:
> On Sun, Feb 19, 2023 at 08:20:43PM -0300, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > On Sun, 19 Feb 2023 at 16:59, Dmitry Shachnev
> wrote:
> > > What are these paths?
> > >
> > > I think one that Helmut mentioned is the most important and should
> cover most
> > > cases.
> >
> > Paths to uic. moc et all.
>
> IIRC, uic and moc produce the same output on all architectures, so we do
> not
> need cross wrappers for them.
>
> So calling the native /usr/lib/qt6/bin/{uic,moc} should be absolutely fine.
Exactly, and that's what I'm trying to check
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
On Sun, Feb 19, 2023 at 08:20:43PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> On Sun, 19 Feb 2023 at 16:59, Dmitry Shachnev wrote:
> > What are these paths?
> >
> > I think one that Helmut mentioned is the most important and should cover
> > most
> > cases.
>
> Paths to uic. moc et all.
IIRC, uic and moc produce the same output on all architectures, so we do not
need cross wrappers for them.
So calling the native /usr/lib/qt6/bin/{uic,moc} should be absolutely fine.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
¡Hola Dmitry! On Sun, 19 Feb 2023 at 16:59, Dmitry Shachnev wrote: > > ¡Hola Lisandro! > > On Sat, Feb 18, 2023 at 11:06:51AM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > I do wonder if we could trick upstream to provide a solution that works for > > everyone. > > qmake cross wrapper is a Debian invention, so it would be hard to explain > to upstream what it is and why they should change their code to support it. Perhaps not in that way, but they might be interested in such a solution now that they should be able to cross compile Qt itself. > On Sat, Feb 18, 2023 at 04:23:21PM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > There seems to be many more paths that need adjustment... or at leats at a > > quick glance. I'll need to find the necessary time to fix this. > > What are these paths? > > I think one that Helmut mentioned is the most important and should cover most > cases. Paths to uic. moc et all. Helmul: is: sbuild -host arm64 -sAd unstable some_qt6_app.dsc a good way to test this? -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
¡Hola Lisandro! On Sat, Feb 18, 2023 at 11:06:51AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > I do wonder if we could trick upstream to provide a solution that works for > everyone. qmake cross wrapper is a Debian invention, so it would be hard to explain to upstream what it is and why they should change their code to support it. On Sat, Feb 18, 2023 at 04:23:21PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > There seems to be many more paths that need adjustment... or at leats at a > quick glance. I'll need to find the necessary time to fix this. What are these paths? I think one that Helmut mentioned is the most important and should cover most cases. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
There seems to be many more paths that need adjustment... or at leats at a quick glance. I'll need to find the necessary time to fix this. signature.asc Description: This is a digitally signed message part.
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
El sábado, 18 de febrero de 2023 11:04:45 -03 Lisandro Damián Nicanor Pérez Meyer escribió: > El sábado, 11 de febrero de 2023 05:50:07 -03 Dmitry Shachnev escribió: > > Hi all, > > [snip] > > > So for Qt 6 something like this may work: > > > > sed -i 's,lib/qt6/libexec/qmake,bin/$(DEB_HOST_GNU_TYPE)-qmake,' \ > > > > debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt6CoreTools/ > > Trying this right now. What I really need to do is to remember to file a > proper bug upstream. Ah, it gets the build architecture path, which is currently OK... I do wonder if we could trick upstream to provide a solution that works for everyone. signature.asc Description: This is a digitally signed message part.
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
El sábado, 11 de febrero de 2023 05:50:07 -03 Dmitry Shachnev escribió: > Hi all, [snip] > So for Qt 6 something like this may work: > > sed -i 's,lib/qt6/libexec/qmake,bin/$(DEB_HOST_GNU_TYPE)-qmake,' \ > debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt6CoreTools/ Trying this right now. What I really need to do is to remember to file a proper bug upstream. signature.asc Description: This is a digitally signed message part.
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
Hi,
On Sat, 11 Feb 2023 at 05:54, Dmitry Shachnev wrote:
>
> Hi all,
>
> On Thu, Feb 09, 2023 at 11:59:43AM +0100, Helmut Grohne wrote:
> > Hi,
> >
> > thanks for adding the -qmake6 wrapper. This piece seems to work
> > fine. The next step is making packages actually use it and this is where
> > it gets difficult.
> >
> > fcitx-qt6 extracts the Qt6::qmake IMPORTED_LOCATION and expects to find
> > a working qmake there. What it gets is the build architecture qmake
> > instead of our lovely wrapper. Bummer.
> >
> > I looked into how this could be fixed and got entangled in the mess of
> > cmake files until I completely lost track. What I found is that the
> > imported location is (wrongly) defined in
> > /usr/lib//cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake as
> > ${_IMPORT_PREFIX}/lib/qt6/libexec/qmake aka /usr/lib/qt6/libexec/qmake
> > while it should be /usr/bin/-qmake6. Tracking down how this
> > file is generated is where I failed. Would someone be available to
> > support me with that task?
>
> In Qt 5 I simply patch that file using sed after dh_auto_install:
>
> https://salsa.debian.org/qt-kde-team/qt/qtbase/-/blob/debian/5.15.8+dfsg-2/debian/rules#L285-L286
>
> So for Qt 6 something like this may work:
>
> sed -i 's,lib/qt6/libexec/qmake,bin/$(DEB_HOST_GNU_TYPE)-qmake,' \
>
> debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake
That's an excellent workaround, but shouldn't that path be different?
If so I can open a bug upstream.
--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
Hi all,
On Thu, Feb 09, 2023 at 11:59:43AM +0100, Helmut Grohne wrote:
> Hi,
>
> thanks for adding the -qmake6 wrapper. This piece seems to work
> fine. The next step is making packages actually use it and this is where
> it gets difficult.
>
> fcitx-qt6 extracts the Qt6::qmake IMPORTED_LOCATION and expects to find
> a working qmake there. What it gets is the build architecture qmake
> instead of our lovely wrapper. Bummer.
>
> I looked into how this could be fixed and got entangled in the mess of
> cmake files until I completely lost track. What I found is that the
> imported location is (wrongly) defined in
> /usr/lib//cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake as
> ${_IMPORT_PREFIX}/lib/qt6/libexec/qmake aka /usr/lib/qt6/libexec/qmake
> while it should be /usr/bin/-qmake6. Tracking down how this
> file is generated is where I failed. Would someone be available to
> support me with that task?
In Qt 5 I simply patch that file using sed after dh_auto_install:
https://salsa.debian.org/qt-kde-team/qt/qtbase/-/blob/debian/5.15.8+dfsg-2/debian/rules#L285-L286
So for Qt 6 something like this may work:
sed -i 's,lib/qt6/libexec/qmake,bin/$(DEB_HOST_GNU_TYPE)-qmake,' \
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
El jueves, 9 de febrero de 2023 07:59:43 -03 Helmut Grohne escribió:
> Package: qt6-base-dev
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> Control: affects -1 + src:fcitx-qt5
>
> Hi,
>
> thanks for adding the -qmake6 wrapper. This piece seems to work
> fine. The next step is making packages actually use it and this is where
> it gets difficult.
>
> fcitx-qt6 extracts the Qt6::qmake IMPORTED_LOCATION and expects to find
> a working qmake there. What it gets is the build architecture qmake
> instead of our lovely wrapper. Bummer.
>
> I looked into how this could be fixed and got entangled in the mess of
> cmake files until I completely lost track. What I found is that the
> imported location is (wrongly) defined in
> /usr/lib//cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake as
> ${_IMPORT_PREFIX}/lib/qt6/libexec/qmake aka /usr/lib/qt6/libexec/qmake
> while it should be /usr/bin/-qmake6. Tracking down how this
> file is generated is where I failed. Would someone be available to
> support me with that task?
I can try...
signature.asc
Description: This is a digitally signed message part.
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
Package: qt6-base-dev
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:fcitx-qt5
Hi,
thanks for adding the -qmake6 wrapper. This piece seems to work
fine. The next step is making packages actually use it and this is where
it gets difficult.
fcitx-qt6 extracts the Qt6::qmake IMPORTED_LOCATION and expects to find
a working qmake there. What it gets is the build architecture qmake
instead of our lovely wrapper. Bummer.
I looked into how this could be fixed and got entangled in the mess of
cmake files until I completely lost track. What I found is that the
imported location is (wrongly) defined in
/usr/lib//cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake as
${_IMPORT_PREFIX}/lib/qt6/libexec/qmake aka /usr/lib/qt6/libexec/qmake
while it should be /usr/bin/-qmake6. Tracking down how this
file is generated is where I failed. Would someone be available to
support me with that task?
Thanks in advance
Helmut
