Summary: | app-emulation/libguestfs-1.36.5 fails src_compile with USE=test ( -Werror=expansion-to-defined ) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kent Fredric (IRC: kent\n) (RETIRED) <kentnl> |
Component: | Current packages | Assignee: | Maxim Koltsov (RETIRED) <maksbotan> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | rich |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=631422 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
libguestfs-1.36.5:20171210-120109.log
cleanup.i.gz |
Description
Kent Fredric (IRC: kent\n) (RETIRED)
2017-12-10 12:22:48 UTC
Meta-point: Is it possible for Gentoo to move to a newer version of libguestfs along the stable branch? Newest is 1.36.11 currently. Since this is a move along the stable branch, there should be no impact except fixing bugs. I agree that werror shouldn't be enabled in distro builds. We recommend it is enabled for upstream developers only. Having said all that, I'm using: glibc-2.26.9000-28.fc28.x86_64 binutils-2.29.1-5.fc28.x86_64 and I don't see any warnings along the stable-1.36 branch. I checked out what this "expansion-to-defined" warning is supposed to mean and I don't understand how it applies here. '-Wexpansion-to-defined' Warn whenever 'defined' is encountered in the expansion of a macro (including the case where the macro is expanded by an '#if' directive). Such usage is not portable. This warning is also enabled by '-Wpedantic' and '-Wextra'. Is Gentoo's _FORTIFY_SOURCE a macro? How is it defined? Can you run the code through cpp and attached the .i file? (In reply to Richard Jones from comment #1) > I agree that werror shouldn't be enabled in distro builds. We recommend it > is enabled for upstream developers only. This is a sort of vague space, because well, the way our workflow works, end-user workflow and developer workflow is somewhat the same. Here, the problem behaviour *only* occurs when some human opts-in to the "test" feature, and the sorts of humans who opt-in to that are sometimes end-users ( who might not care about this ), but are other times "arch-testers" ( who are more likely to care about things like this ) > Is Gentoo's _FORTIFY_SOURCE a macro? How is it defined? Can you run the > code through cpp and attached the .i file? Not sure, working on getting the '.i' file generated, but my make-foo is kinda failing me atm, and can't seem to work out how to invoke anything that will do this. Probably easiest is to cut and paste the long gcc command and add -save-temps to it. There should be a ‘cleanup.i’ file left around. Created attachment 509244 [details]
cleanup.i.gz
Unfortunately cleanup.i contains the compiler input after macro preprocessing (which I should have known) so it doesn't show the error. I'm still unclear what the warning means, but I advise just disable the warning, libguestfs won't work with non-GCC/clang anyway for lots of reasons, portability of some obscure cpp feature isn't a concern. I tried to reproduce this locally using: CFLAGS="-O2 -Wexpansion-to-defined" \ ./configure --enable-werror make but it doesn't reproduce for me. I'm using pretty recent glibc and gcc: glibc-2.26.9000-28.fc28.x86_64 gcc-7.2.1-4.fc28.x86_64 I also think that our use of macros on this line is safe. We're not expanding any macro that I can see which would expand to contain "defined". I suspect this must be something to do with the Gentoo environment ... However we could actually remove the whole section. It was added back in 2009 and I'm not convinced that unconditionally defining _FORTIFY_SOURCE=2 is worthwhile these days given that (a) we use valgrind to routinely test the code and (b) _FORTIFY_SOURCE=2 is defined downstream in many distros. I posted a patch to this effect: https://www.redhat.com/archives/libguestfs/2017-December/msg00036.html The patch I mentioned before is now upstream and hopefully will fix these problems. https://github.com/libguestfs/libguestfs/commit/49263be47aaa2358a0fb12ee90220137ca260b92 The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d5fdb7d569488c4f4a33a6d1cae714d45b5a4f56 commit d5fdb7d569488c4f4a33a6d1cae714d45b5a4f56 Author: Gilles Dartiguelongue <eva@gentoo.org> AuthorDate: 2018-02-07 22:34:53 +0000 Commit: Gilles Dartiguelongue <eva@gentoo.org> CommitDate: 2018-02-07 22:38:48 +0000 app-emulation/libguestfs: version bump 1.36.5 → 1.36.13 * Now compatible with >=glibc-2.26, bug #638180. * Make sure USE=introspection explicitely passes configure switch as we might split glib/gobject from introspection at some point. * Switch to perl-functions eclass as advised in bug #629946. * Restore USE=ocaml as I could not bug #629490 from provided info. * Fix pkg_postinst feature check on USE=gtk. * Fix build with FEATURES=test by disabling -Werror always. It makes no sense to enable this flag for a release, bug #640494. * Add myself to maintainers. Closes: https://bugs.gentoo.org/629690 Closes: https://bugs.gentoo.org/629946 Closes: https://bugs.gentoo.org/638180 Closes: https://bugs.gentoo.org/640494 Package-Manager: Portage-2.3.24, Repoman-2.3.6 app-emulation/libguestfs/Manifest | 1 + app-emulation/libguestfs/libguestfs-1.36.13.ebuild | 173 +++++++++++++++++++++ app-emulation/libguestfs/metadata.xml | 4 + 3 files changed, 178 insertions(+) |