Bug#672085: qof: ftbfs with GCC-4.7
my patch is wrong. see my follow-up in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53285 and choose one of the implementations (the glibc implementation should be ok, as any C compiler in Debian supports anonymous unions). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672085: qof: ftbfs with GCC-4.7
tags 672085 - help tags 672085 + patch On 09.05.2012 04:21, Neil Williams wrote: tag 672085 + help quit On Tue, 08 May 2012 18:57:52 + Matthias Klose d...@debian.org wrote: user debian-...@lists.debian.org usertags 672085 + ftbfs-gcc-4.7 thanks The build failure is exposed by building with gcc-4.7/g++-4.7, which is now the default gcc/g++ on x86 architectures. Some hints on fixing these issues can be found at http://gcc.gnu.org/gcc-4.7/porting_to.html This particular issue isn't covered in those hints, it's an internal MD5 process which is the same as the internal MD5 code in eglibc. I could hide the problem by dropping -Werror or adding -fno-strict-aliasing but it's not clear to me why the same code compiles in eglibc and not in qof, especially when eglibc is passing -fstrict-aliasing. I'm fairly sure that this needs no source code changes in md5.c, this is something related to the build system options but I have to admit I can't quite see where it lies currently. (Due to the history of the code in QOF, exactly the same code still exists in all versions of GnuCash.) this is fixed in newer eglibc releases, at least for 2.15. see the attached patch. Index: libiberty/md5.c === --- libiberty/md5.c (revision 187927) +++ libiberty/md5.c (working copy) @@ -114,9 +114,9 @@ memcpy (ctx-buffer[bytes], fillbuf, pad); /* Put the 64-bit file length in *bits* at the end of the buffer. */ - *(md5_uint32 *) ctx-buffer[bytes + pad] = SWAP (ctx-total[0] 3); - *(md5_uint32 *) ctx-buffer[bytes + pad + 4] = SWAP ((ctx-total[1] 3) | - (ctx-total[0] 29)); + ctx-buffer[(bytes + pad) / 4] = SWAP (ctx-total[0] 3); + ctx-buffer[(bytes + pad + 4) / 4] = SWAP ((ctx-total[1] 3) | +(ctx-total[0] 29)); /* Process last bytes. */ md5_process_block (ctx-buffer, bytes + pad + 8, ctx);
Bug#672085: qof: ftbfs with GCC-4.7
user debian-...@lists.debian.org usertags 672085 + ftbfs-gcc-4.7 thanks The build failure is exposed by building with gcc-4.7/g++-4.7, which is now the default gcc/g++ on x86 architectures. Some hints on fixing these issues can be found at http://gcc.gnu.org/gcc-4.7/porting_to.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672085: qof: ftbfs with GCC-4.7
tag 672085 + help quit On Tue, 08 May 2012 18:57:52 + Matthias Klose d...@debian.org wrote: user debian-...@lists.debian.org usertags 672085 + ftbfs-gcc-4.7 thanks The build failure is exposed by building with gcc-4.7/g++-4.7, which is now the default gcc/g++ on x86 architectures. Some hints on fixing these issues can be found at http://gcc.gnu.org/gcc-4.7/porting_to.html This particular issue isn't covered in those hints, it's an internal MD5 process which is the same as the internal MD5 code in eglibc. I could hide the problem by dropping -Werror or adding -fno-strict-aliasing but it's not clear to me why the same code compiles in eglibc and not in qof, especially when eglibc is passing -fstrict-aliasing. I'm fairly sure that this needs no source code changes in md5.c, this is something related to the build system options but I have to admit I can't quite see where it lies currently. (Due to the history of the code in QOF, exactly the same code still exists in all versions of GnuCash.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpNAZp0HUlGT.pgp Description: PGP signature
Bug#672085: qof: ftbfs with GCC-4.7
On 08.05.2012 22:21, Neil Williams wrote: tag 672085 + help quit On Tue, 08 May 2012 18:57:52 + Matthias Klose d...@debian.org wrote: user debian-...@lists.debian.org usertags 672085 + ftbfs-gcc-4.7 thanks The build failure is exposed by building with gcc-4.7/g++-4.7, which is now the default gcc/g++ on x86 architectures. Some hints on fixing these issues can be found at http://gcc.gnu.org/gcc-4.7/porting_to.html This particular issue isn't covered in those hints, it's an internal MD5 process which is the same as the internal MD5 code in eglibc. I could hide the problem by dropping -Werror or adding -fno-strict-aliasing but it's not clear to me why the same code compiles in eglibc and not in qof, especially when eglibc is passing -fstrict-aliasing. eglibc doesn't use the default compiler, but the warning is still seen when building a recent libiberty (e.g. in gcc-4.7, or gcc-snapshot). forwarded to http://gcc.gnu.org/PR53285 for now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
