I don't know the build system for this program (and this is a generic bug template so I cannot tell you which program exactly is), but my tests shows that it's not respecting CFLAGS (or CXXFLAGS) properly. Please look into it, since it's important to respect user CFLAGS and CXXFLAGS. Warning: this bug might look like a false positive because you actually have your CFLAGS being used; this happens if the CFLAGS are "set in stone" in the build system during src_unpack/src_prepare. While QA has not as of this moment expressed to me a preference, I'd sincerely suggest to avoid the set-in-stone approach, so that ebuild commands could work to reproduce the actual results. To avoid the set in stone approach: - consider just changing CFLAGS= to CFLAGS+= if the build system enables warnings; - if the buildsystem does not use CFLAGS variable at all, in the sed use '$(CFLAGS)', single quoted, so that the CFLAGS variable is picked up; - use '$(OPTCFLAGS)' in the sed and then use make OPTCFLAGS=$CFLAGS. Thanks, Diego
commit 4699e319cf956c040a73eae249c3392964263ac0 Author: Michael Orlitzky <mjo@gentoo.org> Date: Thu Aug 11 13:25:14 2016 -0400 net-ftp/tlswrap: new revision that respects CFLAGS. This new revision comes with a few patches, the first of which updates configure.ac to respect the user's CFLAGS. After that, the second patch modernizes the AM_INIT_AUTOMAKE call to avoid an ugly warning. Finally -- now that the build respects CFLAGS -- the package needed to be updated to build with -Werror=format-security. Those fixes were trivial and come in a third patch. The only change to the ebuild itself (aside from the patches) was a new call to eautoreconf, to pick up the aforementioned changes. Gentoo-Bug: 240898 Package-Manager: portage-2.2.28
