Bug#919453: mumble FTCBFS: builds for the wrong architecture

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#919453: mumble FTCBFS: builds for the wrong architecture

Helmut Grohne
Source: mumble
Version: 1.3.0~git20190114.9fcc588+dfsg-1
Tags: patch
User: [hidden email]
Usertags: rebootstrap

mumble fails to cross build from source, because it calls the build
architecture qmake. It actually calls qmake twice: Once via
dh_auto_configure and once directly from debian/rules. The call via
dh_auto_configure uses the right qmake, but the wrong flags. Merging
those calls into one fixes this part. Then mumble hard codes the build
architecture pkg-config in a lot of places. Making those calls
substitutable should be upstreamable and makes mumble cross buildable.
Please consider applying the attached patch.

Helmut

mumble_1.3.0~git20190114.9fcc588+dfsg-1.1.debdiff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919453: mumble FTCBFS: builds for the wrong architecture

Chris Knadle
Helmut Grohne:

> Source: mumble
> Version: 1.3.0~git20190114.9fcc588+dfsg-1
> Tags: patch
> User: [hidden email]
> Usertags: rebootstrap
>
> mumble fails to cross build from source, because it calls the build
> architecture qmake. It actually calls qmake twice: Once via
> dh_auto_configure and once directly from debian/rules. The call via
> dh_auto_configure uses the right qmake, but the wrong flags. Merging
> those calls into one fixes this part. Then mumble hard codes the build
> architecture pkg-config in a lot of places. Making those calls
> substitutable should be upstreamable and makes mumble cross buildable.
> Please consider applying the attached patch.
>
> Helmut

I was not aware that dh_auto_configure is calling qmake such that there were
duplicate calls; I'd like to fix that.  I'd also like to have Mumble be cross
buildable.

I had a chance to review the patch.  The fix hinges on this function call:

   PKG_CONFIG = $$pkgConfigExecutable()

Could you let me know where this function call exists, i.e. what package it's in
so I can look at it?  I haven't been able to find it, and to try to get a patch
upstream I need to understand and be able to explain what this is for and what
it does.

Thanks
   -- Chris

--
Chris Knadle
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#919453: mumble FTCBFS: builds for the wrong architecture

Helmut Grohne
Hi Chris,

On Wed, Jan 16, 2019 at 04:52:35PM +0000, Chris Knadle wrote:

> > mumble fails to cross build from source, because it calls the build
> > architecture qmake. It actually calls qmake twice: Once via
> > dh_auto_configure and once directly from debian/rules. The call via
> > dh_auto_configure uses the right qmake, but the wrong flags. Merging
> > those calls into one fixes this part. Then mumble hard codes the build
> > architecture pkg-config in a lot of places. Making those calls
> > substitutable should be upstreamable and makes mumble cross buildable.
> > Please consider applying the attached patch.
>
> I was not aware that dh_auto_configure is calling qmake such that there were
> duplicate calls; I'd like to fix that.  I'd also like to have Mumble be cross
> buildable.

dh_auto_configure figures out what kind of build system is to be used
and issues the corresponding call. In your case, it figures that it
should call qmake. My patch stuffs your qmake flags into
dh_auto_configure's qmake call.

> I had a chance to review the patch.  The fix hinges on this function call:
>
>    PKG_CONFIG = $$pkgConfigExecutable()
>
> Could you let me know where this function call exists, i.e. what package it's in
> so I can look at it?  I haven't been able to find it, and to try to get a patch
> upstream I need to understand and be able to explain what this is for and what
> it does.

Unfortunately, I cannot precisely answer that question. I'll have to
defer to Lisandro or Dmitry (both Cced here). In any case, the reason is
that your dependencies (aka .pc files) may be present for multiple
architectures and for cross building that matters. So you need to
somehow specify to pkg-config, which architecture you are interested in.
On Debian systems you do that by invoking a different pkg-config.
Typically, that's ${DEB_HOST_GNU_TYPE}-pkg-config. So I can tell, what
this call does (but not where it comes from): It returns the pkg-config
that the user (in this case dh_auto_configure) supplied to the build.

A quick codesearch[1] reveals that it is defined somewhere in
qtbase-opensource-src, so it should come with any qmake installation
based on qt5.

Does that help already? If not, please follow up with Lisandro and
Dmitry.

And yes, I specifically tried to write that patch in an upstreamable
manner. If that doesn't work, I'm happy to adapt for future patches.

Helmut

[1] https://codesearch.debian.net/search?q=pkgConfigExecutable

Reply | Threaded
Open this post in threaded view
|

Bug#919453: mumble FTCBFS: builds for the wrong architecture

Lisandro Damián Nicanor Pérez Meyer-2
Hi everyone!

El miércoles, 16 de enero de 2019 14:53:19 -03 Helmut Grohne escribió:
> Hi Chris,
>
[snip]

> > I had a chance to review the patch.  The fix hinges on this function call:
> >    PKG_CONFIG = $$pkgConfigExecutable()
> >
> > Could you let me know where this function call exists, i.e. what package
> > it's in so I can look at it?  I haven't been able to find it, and to try
> > to get a patch upstream I need to understand and be able to explain what
> > this is for and what it does.
>
> Unfortunately, I cannot precisely answer that question. I'll have to
> defer to Lisandro or Dmitry (both Cced here). In any case, the reason is
> that your dependencies (aka .pc files) may be present for multiple
> architectures and for cross building that matters. So you need to
> somehow specify to pkg-config, which architecture you are interested in.
> On Debian systems you do that by invoking a different pkg-config.
> Typically, that's ${DEB_HOST_GNU_TYPE}-pkg-config. So I can tell, what
> this call does (but not where it comes from): It returns the pkg-config
> that the user (in this case dh_auto_configure) supplied to the build.
>
> A quick codesearch[1] reveals that it is defined somewhere in
> qtbase-opensource-src, so it should come with any qmake installation
> based on qt5.
qmake as a build system has support for using pkgconfig. I have not used this
myself (I strongly prefer CMake), but glazing at the code it's just the way
qmake passes the path to pkgconfig.

Kinds regards, Lisandro.

--
"A computer is like an air conditioner. It stops working when you open
windows."

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#919453: mumble FTCBFS: builds for the wrong architecture

Chris Knadle
Lisandro Damián Nicanor Pérez Meyer:
> Hi everyone!

Greetings again Lisandro. :)

> El miércoles, 16 de enero de 2019 14:53:19 -03 Helmut Grohne escribió:
>> Hi Chris,
>>
> [snip]
>>> I had a chance to review the patch.  The fix hinges on this function call:
>>>    PKG_CONFIG = $$pkgConfigExecutable()
>>>
>>> Could you let me know where this function call exists, i.e. what package
>>> it's in so I can look at it?  I haven't been able to find it, and to try
>>> to get a patch upstream I need to understand and be able to explain what
>>> this is for and what it does.
>>
>> Unfortunately, I cannot precisely answer that question. I'll have to
>> defer to Lisandro or Dmitry (both Cced here). In any case, the reason is
>> that your dependencies (aka .pc files) may be present for multiple
>> architectures and for cross building that matters. So you need to
>> somehow specify to pkg-config, which architecture you are interested in.
>> On Debian systems you do that by invoking a different pkg-config.
>> Typically, that's ${DEB_HOST_GNU_TYPE}-pkg-config. So I can tell, what
>> this call does (but not where it comes from): It returns the pkg-config
>> that the user (in this case dh_auto_configure) supplied to the build.
>>
>> A quick codesearch[1] reveals that it is defined somewhere in
>> qtbase-opensource-src, so it should come with any qmake installation
>> based on qt5.
>
> qmake as a build system has support for using pkgconfig. I have not used this
> myself (I strongly prefer CMake), but glazing at the code it's just the way
> qmake passes the path to pkgconfig.
Looking at the code (below), that sounds right.

This is what I was looking for:

root@code-devel:/# fgrep -r pkgConfigExecutable /usr/*
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf:defineReplace(pkgConfigExecutable)
{
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf:    pkg_config =
$$pkgConfigExecutable()

root@code-devel:/# dpkg -S
/usr/lib/x85_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf
qt5-qmake:amd64: /usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf

So it's part of the qt5-qmake package, thus part of Qt5 itself.  That's most of
what I needed to know.

The code section in qt_functions.prf:

[...]
defineReplace(pkgConfigExecutable) {
    isEmpty(PKG_CONFIG) {
        !isEmpty(QMAKE_PKG_CONFIG): \
            PKG_CONFIG = $$QMAKE_PKG_CONFIG
        else: \
            PKG_CONFIG = pkg-config

        sysroot.name = PKG_CONFIG_SYSROOT_DIR
        sysroot.value = $$PKG_CONFIG_SYSROOT_DIR
        libdir.name = PKG_CONFIG_LIBDIR
        libdir.value = $$PKG_CONFIG_LIBDIR
        QT_TOOL_NAME = pkg-config
        qtAddToolEnv(PKG_CONFIG, sysroot libdir, SYS)
    }

    equals(QMAKE_HOST.os, Windows): \
        PKG_CONFIG += 2> NUL
    else: \
        PKG_CONFIG += 2> /dev/null

    return($$PKG_CONFIG)
}
[...]

I'm satisfied.  I'll open an issue with Mumble upstream to see if I can get the
patch incorporated for Mumble 1.3.  The build for mumble
1.3.0~git20190114.9fcc588+dfsg-1 hasn't completed for 3 architectures, and I'd
like to wait the 5 days for the package to transition to Testing/Buster -- I
plan to upload a package with the patch after that.

Thanks very much for this work.

   -- Chris

--
Chris Knadle
[hidden email]


signature.asc (849 bytes) Download Attachment