GNOME Bugzilla – Bug 784466
alignment: fix armel/armhf/mipsel build failure
Last modified: 2017-07-04 16:22:05 UTC
This commit extends commit faf1e24edf0cc77a189 "zoom-manager: bring back attribute aligned(8)" to both places where the attribute was previously dropped from in commit 63579451b5073b9ce3 "alignment: set alignment on structs". 3.22.3 + commit 6a3d7282ec737 + commit faf1e24edf0cc + this patch has been successfully build tested on Debian armhf porterbox (harris.debian.org). (It also means we end up with exactly the same as the 3.22.2 + patch situation currently shipped in Debian 'stretch' 9.0 regarding alignment/cast fixes.)
Created attachment 354817 [details] [review] alignment: fix armel/armhf/mipsel build failure
Once this change has been reviewed and committed to master, any objections if I start a sysprof-3-22 branch based on 3.22.3 and cherry-pick some fixes? I guess there's not enough upstream bandwidth to maintain ongoing 3.22 branch but we're shipping 3.22 in Debian and IMHO would be better if we maintain it upstream in case anyone else are interested. My plan would be: Branch from 3.22.3 and then cherry-pick commit 6a3d7282ec737 + commit faf1e24edf0cc + this patch
Yeah this sounds fine to me. Do you have commit access to setup the branch? I can do it, but if you can too, that saves me time. Another thing I'd strongly consider, is that Debian looks into adding that attribute to their GObject type definition in libgobject-2.0 for ARM/Mips/etc. GObject uses GSlice which is guaranteed to return allocations with alignments >= 2*sizeof(void*) so this is 100% a false positive by the compiler as we would always at least have an 8-byte alignment. I also think that GObject should get this attribute upstream. See bug 776028 I think it is important to note that Sysprof was designed and written for x86/x86_64 and has very little to no testing on any other platform. I know of exactly one person who has used it on Arm. The fact that it compiles on these platforms is more of an accident than anything else. I don't see why it can't work, I just haven't tested it *at all*.
(In reply to Christian Hergert from comment #3) > Yeah this sounds fine to me. Do you have commit access to setup the branch? > I can do it, but if you can too, that saves me time. Done. Pushed the patch to master + set up sysprof-3-22 branch with cherry-picks. > > Another thing I'd strongly consider, is that Debian looks into adding that > attribute to their GObject type definition in libgobject-2.0 for > ARM/Mips/etc. > > GObject uses GSlice which is guaranteed to return allocations with > alignments >= 2*sizeof(void*) so this is 100% a false positive by the > compiler as we would always at least have an 8-byte alignment. I also think > that GObject should get this attribute upstream. See bug 776028 > > I think it is important to note that Sysprof was designed and written for > x86/x86_64 and has very little to no testing on any other platform. I know > of exactly one person who has used it on Arm. The fact that it compiles on > these platforms is more of an accident than anything else. I don't see why > it can't work, I just haven't tested it *at all*. To tell you the truth I have limited interest in these architectures. My interest is basically making sure they continue to build, otherwise debian testing migration systems sees that as a regression and won't let anything (including x86) migrate. If someone (like for example the Debian arm porter team) has higher ambitions they should feel free to contribute. ;)