Backporting dpkg 1.17.25 to Trusty with No Change gets checking whether the C compiler works... no

Asked by Pascal Mons on 2018-10-29

I am trying to backport dpkg 1.17.25 to Trusty 14.04.
I am using the source and debian from
With no change at all in my PPA

It also build flawlessly on my Ubuntu Xenial 16.04

Then I get with Launchpad

checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/<<PKGBUILDDIR>>/build-tree':
configure: error: C compiler cannot create executables

Then I saw that gcc was not part of the build-depends in debian/control and I added it to no avail, as I get the exact same error ...

What is going on here ? Why Launchpad refuses to use the gcc compiler ?

Question information

English Edit question
Launchpad itself Edit question
No assignee Edit question
Solved by:
Colin Watson
Last query:
Last reply:
Pascal Mons (anton+) said : #1

Still more to this story ...
It looks like someone uploaded 2 packages in his own PPA :

debhelper - 9.20150101ubuntu1~ubuntu14.04.1york2
dpkg - 1.17.25ubuntu1.1~ubuntu14.04.1york1

of which dpkg is exactly the same source and debian I am uploadig to my PPA to the very Ubuntu series Trusty 14.04 ...
Then I went on to copy both packages from his PPA opting for the same series (of course) and selecting:

Rebuild the copied sources

And the build failed again with the same error:

checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/<<PKGBUILDDIR>>/build-tree':
configure: error: C compiler cannot create executables

So why on earth Launchpad did work correctly on March, 4th 2016 and right now it won't ?

There is definitively something wrong in Launchpad at this moment ... I believe you did make changes since March 2016 which adversely affects some pristine sources (coming from Ubuntu) builds.

Will take it seriously ?

Side note: debhelper did rebuild flawlessly.

Best Colin Watson (cjwatson) said : #2

In short: this is not a Launchpad problem. The person who did the backport you're trying to copy had arranged for their PPA to use another PPA that provides GCC 4.9 as part of its build-dependencies.

Backporting dpkg or debhelper is usually a sign that you need to make different choices: it's almost always easier to change higher layers to avoid needing new versions of either of those. If you do decide to do that kind of backport, then you must be knowledgeable about investigating problems with build-dependencies.

A good technique when the configure script fails like this is to arrange (in debian/rules) to "cat config.log" after the failure. If you'd done this, then you'd see this among the output:

configure:3201: gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro conftest.c >&5
gcc: error: unrecognized command line option '-fstack-protector-strong'

dpkg 1.17.11 added support for a new "stackprotectorstrong" hardening build flag, enabled by default. (And, for self-consistency, the dpkg build process uses its own preferred build flags as part of the build process rather than those of the installed version of dpkg-dev.) "man dpkg-buildflags" says: "This feature has the same requirements as stackprotector, and in addition also requires gcc 4.9 and later." Now, trusty had gcc 4.8; so dpkg's configure script tries to invoke the compiler with its configured compiler options, the compiler fails, and it gives up. Nothing to do with Launchpad being broken; you could have reproduced the exact same failure locally using sbuild.

The choices in this case, in roughly descending order of difficulty, are:

 1) Backport GCC 4.9 too;
 2) Configure your PPA's dependencies to add another PPA where somebody's already backported GCC 4.9;
 3) Modify your dpkg backport to disable this new hardening build flag so that it doesn't require GCC 4.9;
 4) Delete the attempted dpkg and debhelper backports from your PPA and instead modify the packages that led you down the rabbit-hole of backporting dpkg and debhelper in the first place so that they can build with trusty's versions of dpkg and debhelper.

I would strongly recommend 4).

If you must go with any of the other options for whatever reason, then you really need to become proficient at reproducing this sort of problem locally, and not jump to the assumption that Launchpad is broken before you've ruled out the possibility of a problem in your build or in one of its build-dependencies; otherwise it will be a long and tortuous process. I recommend sbuild (e.g. for this. Reasonably recent versions have the --extra-repository and related options that make it quite straightforward to run test builds using a given PPA.

Pascal Mons (anton+) said : #3

OK. Great. Thanks for your insight.
Everything is fine right now.

Pascal Mons (anton+) said : #4

Thanks Colin Watson, that solved my question.