libgdiplus is not currently using the default build flags set by dpkg-buildflags(1).
The default flags are chosen for multiple reasons including security,
performance, reproducibility, adherence to standards, and error handling.

Please make sure that libgdiplus builds using the default build flags. blhc(1p)
and hardening-check(1) can be used to confirm that the issue is fixed.

In the general case, packages honoring CFLAGS, LDFLAGS, and other
similar environment variables get the default build flags for free
without the need for any work on the maintainer side. In the case of
libgdiplus, the flags are either ignored or overridden.

The most common reasons for this are:

Hand-written Makefiles
----------------------
Some upstream Makefiles either override the values of variables such as
CFLAGS and similar or do not use them at all. See:
https://wiki.debian.org/HardeningWalkthrough#Handwritten_Makefiles

Misconfigured build systems
---------------------------
If the upstream code uses autotools, CMake, or other popular build
systems, it usually requires no further modifications. If might however
be that some variables are hardcoded in some way.

In this CMake snippet, the value of CXXFLAGS is overwritten with "-O2":

 set(CMAKE_CXX_FLAGS "-O2")

If the intention is to append to CXXFLAGS, one should use the following
instead:

 set(CMAKE_CXX_FLAGS "-O2 ${CMAKE_CXX_FLAGS}")

See #655870 for a similar autotools example.

Very old debhelper usage
------------------------
Packages not using dh(1), or those using a debhelper compatibility level
less than 9, need to manually include /usr/share/dpkg/buildflags.mk in
order for the dpkg-buildflags variables to be set:
https://wiki.debian.org/Hardening#dpkg-buildflags

Flags hardcoded in debian/rules (either voluntarily or not)
-----------------------------------------------------------
Some packages voluntarily hardcode the values of CFLAGS and friends in
debian/rules, ignoring the defaults set by dpkg-buildflags(1).

Others attempt to append to the variables, but end up accidentally
overriding the defaults:

 #!/usr/bin/make -f
 export CFLAGS += -pipe -fPIC -Wall

 %:
 	dh $@

Debhelper only sets CFLAGS if it is not set yet. In the example above,
when dh is invoked the value of CFLAGS is "-pipe -fPIC -Wall", hence the
hardened defaults are not used. The right way to append to CFLAGS is
using DEB_CFLAGS_MAINT_APPEND instead, as documented in
dpkg-buildflags(1).

For a detailed analysis of this issue, see:
https://people.debian.org/~ema/nocflags_paper.pdf (eprint: hal-05334704)

Hi,

I reproduced this on current libgdiplus 6.1+dfsg-1.2 and prepared a tested
fix in debian/rules. Attached is the scoped debian/rules fix I prepared
against libgdiplus 6.1+dfsg-1.2.

For this bug specifically, the fix imports dpkg build flags through
/usr/share/dpkg/buildflags.mk and exports CPPFLAGS, CFLAGS and LDFLAGS so the
package again uses the normal dpkg-buildflags set. In the resulting build, the
compiler command lines include the expected hardening and reproducibility
flags.

Validation on the patched tree: dpkg-buildpackage -b succeeds;
dpkg-buildpackage -S succeeds afterwards on the same tree; a clean
unstable-amd64-sbuild succeeds; piuparts passes when run for amd64.

The separate vendored Googletest compatibility failure is tracked in #1135544
and is not part of this patch.

Since libgdiplus is currently orphaned (#1079870), I am sending this as an
adoption/QA-style handoff rather than assuming an active maintainer workflow.

Regards,
James