• Bug#1079489: dpkg-dev: buildflags.mk messes with string double quoting

    From Andrea Pappacoda@1:229/2 to All on Fri Aug 23 23:00:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    [SoupGate killed MIME-encoded file 00000000.ATT (10163 bytes)]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Andrea Pappacoda on Sun Sep 29 00:40:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    Control: block -1 by 1029106

    [ Nicolas CCed you only FYI. :) ]

    Hi!

    On Fri, 2024-08-23 at 22:54:05 +0200, Andrea Pappacoda wrote:
    Package: dpkg-dev
    Version: 1.22.11
    Severity: normal

    Hi! I've just noted a strange behaviour of buildflags.mk. In short, including the file seems to remove some level of string quoting from preprocessor flags defined with DEB_CPPFLAGS_MAINT_APPEND, almost as if the value was passed to a
    shell one too many times. It is simpler to explain this with an example.

    Let's suppose the upstream software requires you to define a preprocessor variable with a string value, like this one:

    […]

    As you can see, the package builds and runs as expected, and the compiler is invoked with -DFOO='"string_value"'. The issue presents when including /usr/share/dpkg/buildflags.mk, just after the shebang line:

    […]

    As you can see, in the second run the compiler is invoked with -DFOO='string_value'. The double quotes get removed, even if surrounded with single quotes; this of course leads to build failures.

    It is worth noting that the issue presents also when invoking "debian/rules binary" directly, without delegating to dpkg-buildpackage.

    This seems to me like a bug in buildflags.mk, but I may be doing something stupid I don't notice.

    I'm afraid, that while suboptimal, the behavior is currently what it is,
    and modifying it would break existing debian/rules files that expect the current behavior. :/ Also I'm not sure we could fix this easily with the current GNU make in Debian.

    I think the main roadblock is that GNU make does not pass exported make variables into $(shell) function invocations, which I think is what is
    probably causing the shell evaluation and mangling of these values. But
    the version supporting that, is not even in Debian:

    ,--- NEWS ---
    Version 4.4 (31 Oct 2022)

    […]

    * WARNING: Backward-incompatibility!
    Previously makefile variables marked as export were not exported to
    commands started by the $(shell ...) function. Now, all exported
    variables are exported to $(shell ...). If this leads to recursion
    during expansion, then for backward-compatibility the value from the
    original environment is used. To detect this change search for
    'shell-export' in the .FEATURES variable.
    `---

    I guess this could be considered as part of the work to reintroduce the performance optimizations that Nicolas worked on, or a later iteration
    on that once we have a fixed GNU make, where we could introduce this
    through a dpkg-build-api level for example, and tie that into requiring
    a fixed GNU make version.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)