gnupg-1.4.9-5.fc11.src.rpm Failed To Build From Source against the rawhide tree. See http://fedoraproject.org/wiki/FTBFS for more information.
Setting to ASSIGNED per Fedora Bug Triage workflow. https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Created attachment 352540 [details] root.log root.log for i386
Created attachment 352541 [details] build.log build.log for i386
Created attachment 352542 [details] mock.log mock.log for i386
Created attachment 352543 [details] root.log root.log for x86_64
Created attachment 352544 [details] build.log build.log for x86_64
Created attachment 352545 [details] mock.log mock.log for x86_64
Hmm, __builtin_object_size() doesn't seem to allow for how gnupg allocates and uses "struct para_data_s" in g10/keygen.c. Changing the way the structure is laid out will work as a temporary fix, but we should probably ask the toolchain folks about it, too.
Created attachment 354021 [details] cut-down reproducer
Created attachment 354030 [details] repro.i preprocessed version of repro.c (attachment #354021 [details])
Jakub, I boiled down the code in gnupg that crashes during the test suite down to attachment #354030 [details]. Building it with -O2 using gcc-4.4.0-12 triggers __fortify_fail on my x86_64 system. Do you know if this is something that gcc needs to be allowing for, or should I be looking at reworking the structure definition in gnupg? I'd appreciate any advice you have. Thanks!
Yes, this is considered invalid for str*/stp* functions with -D_FORTIFY_SOURCE=2 (valid for -D_FORTIFY_SOURCE=1 and -U_FORTIFY_SOURCE). Either use memcpy instead of strcpy (memcpy accross field boundaries is valid even with -D_FORTIFY_SOURCE=2, memcpy (l->u.value, "DSA", sizeof "DSA")), or rework the data structures. Say: struct list_item { struct list_item *next; int blah; }; union list_item_union { struct list_item header; struct list_item_foo { struct list_item header; foo *foo; } foo; struct list_item_bar { struct list_item header; bar *bar; } bar; struct list_item_baz { struct list_item header; uint32_t baz; } baz; struct list_item_value { struct list_item header; char value[1]; } value; }; should work (or obviously you can have union for the stuff you don't abuse as wannabe flexible array member).
Is there a reference for what's valid and what isn't? I've found mention of some things that aren't valid in assorted bug reports and mailing list archives, but haven't found a full list to check against. I'd like to avoid proposing a change upstream that happens to be accepted now but later turns out to be problematic.
Actually, now that I got another similar report (#512689), after some discussions on upstream IRC I'm considering allowing this: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01136.html
Thanks, Jakub! The scratch build now succeeds with 4.4.0-15, so I'll mark this as fixed in Raw Hide.