On 3 Sep 2012, at 16:49, Jason Edgecombe wrote: > The gcc upgrade (4.4.5) seems to have uncovered some compilation issues: > make[3]: Entering directory `/home/buildmaster/git/src/tptserver' > gcc -O2 -Wall -Wstrict-prototypes -Wold-style-definition -Werror > -fdiagnostics-show-option -Wpointer-arith -I/home/buildmaster/git/src/config > -I/home/buildmaster/git/include -I. -I. -pthread -D_REENTRANT > -DAFS_PTHREAD_ENV -o ptutils.o -c ./../ptserver/ptutils.c > cc1: warnings being treated as errors > ./../ptserver/ptutils.c: In function ‘ChangeEntry’: > ./../ptserver/ptutils.c:1964: error: dereferencing pointer ‘tent.243’ does > break strict-aliasing rules [-Wstrict-aliasing] > ./../ptserver/ptutils.c:1964: note: initialized from here > ./../ptserver/ptutils.c: In function ‘RemoveFromSGEntry’: > ./../ptserver/ptutils.c:813: error: dereferencing pointer ‘tentryg’ does > break strict-aliasing rules [-Wstrict-aliasing] > ./../ptserver/ptutils.c:798: error: dereferencing pointer ‘tentryg’ does > break strict-aliasing rules [-Wstrict-aliasing] > ./../ptserver/ptutils.c:767: error: dereferencing pointer ‘tentryg’ does > break strict-aliasing rules [-Wstrict-aliasing] > ./../ptserver/ptutils.c:766: error: dereferencing pointer ‘tentryg’ does > break strict-aliasing rules [-Wstrict-aliasing] > ./../ptserver/ptutils.c:763: note: initialized from here > make[3]: *** [ptutils.o] Error 1 > make[3]: Leaving directory `/home/buildmaster/git/src/tptserver' > make[2]: *** [tptserver] Error 2 > make[2]: Leaving directory `/home/buildmaster/git' > make[1]: *** [build] Error 2 > make[1]: Leaving directory `/home/buildmaster/git' > make: *** [all] Error 2
This looks like the same problems with aliasing when supergroups is enabled that f2db78a346112f5320efc6f0b6b9fe4ae0d893d3 fixed in the non-pthreaded build. I've tried pushing a fix to gerrit (8035) which copies the same build rules that we use to work around this in the ptserver directory to the tptserver one, and we'll see if that hides the problem. At some point, we're going to have to bite the bullet and rework the supergroups code so that we don't have these issues, but that's going to require significant changes, as the supergroups code plays fast and loose with structure definitions. Cheers, Simon. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
