Red Hat Bugzilla – Bug 295521
-fno-strict-aliasing breaks hugin build
Last modified: 2008-02-20 16:14:57 EST
Description of problem: The latest wxGTK package is compiled with -fno-strict-aliasing, this causes the following build failure when I try to compile hugin: /usr/include/wx-2.8/wx/filename.h: In static member function 'static wxChar wxFileName::GetPathSeparator(wxPathFormat)': /usr/include/wx-2.8/wx/filename.h:393: error: ambiguous overload for 'operator[]' in 'wxFileName::GetPathSeparators(wxPathFormat)()[0u]' /usr/include/wx-2.8/wx/filename.h:393: note: candidates are: operator[](const wxChar*, long int) <built-in> /usr/include/wx-2.8/wx/string.h:822: note: wxChar& wxString::operator[](int) /usr/include/wx-2.8/wx/string.h:824: note: wxChar& wxString::operator[](size_t) See this thread: http://thread.gmane.org/gmane.comp.misc.ptx/7266 Version-Release number of selected component (if applicable): 2.8.4-3.fc7 How reproducible: Always Steps to Reproduce: 1. compile hugin, fails 2. rebuild wxGTK without -fno-strict-aliasing 3. compile hugin, ok Additional info: I'm reporting this here as the fedora package change triggers the problem, though clearly the bug is in some bit of code which I'm not in a position to identify.
The wxGTK code doesn't follow the strict aliasing rules, so it has to have that optimization disabled. Turning it on is inviting possible subtle and difficult-to-track-down bugs. I'm not saying this isn't triggering some *other* bug, but I think it's more likely that having the optimization on is hiding the problem, not fixing it.
Any ideas for tracking this down? As far as I can tell the problem could be in wxwidgets or hugin and my C++ skills don't really exist. The hugin package in rawhide was built one day before this wxGTK landed, but this is preventing any future rebuilds.
Well, the error above notes that it can't decide if 0u should be handled by wxString::operator[](int) or by wxString::operator[](size_t). What happens if you change line 393 in /usr/include/wx-2.8/wx/filename.h to say either just [0] or [static_cast<size_t>(0)] instead of [0u]?
(I tried building hugin with -no-strict-aliasing, but this made no difference, same error) However I changed wx/filename.h:393 from [0u] to [0] as you suggest and hugin now builds ok.
(In reply to comment #4) > However I changed wx/filename.h:393 from [0u] to [0] as you suggest and hugin > now builds ok. Sorry that wasn't clear, I changed wx/filename.h and the normal unmodified hugin built fine without any special CFLAGS.
Okay, cool. I'll check with upstream to see what they think about that, and in the meantime I think I can patch our rpm to make that change -- I'm pretty sure it can't hurt.
I'm really busy right now; I can make the patched packages for Fedora today, but I won't have time to figure out the issue upstream until sometime next week. If you have a chance to bring this up on the wx-dev mailing list that might expedite things.
(In reply to comment #7) I'd be out of my depth, I can't speak with any authority about what this problem is.
Matthew: Please do rebuild the updated packages as soon as you can. This his holding build of a security fix. Thanks!
Busy this afternoon. Tonight or tomorrow.
I can't find these new RPMS for wxGTK anywhere. Were they made & released?
(In reply to comment #11) > I can't find these new RPMS for wxGTK anywhere. Were they made & released? There are no new wxGTK RPMs, hugin needed to be re-released due to bug #332401 and it built ok - So this problem doesn't appear in mock. However I have more identical bug reports, and I can reproduce this on a fresh fedora-8 x86_64 system (a normal build breaks, but mock is ok). So my best guess is that this is a multiarch problem, this bug could be closed as it may or may not be wxGTK specific.
(In reply to comment #12) > > So my best guess is that this is a multiarch problem Yes, this is it. Removing all wxGTK packages with --nodeps, then installing only wxGTK.x86_64 and wxGTK-devel.x86_64 leaves me with a working build-system. So this is a dupe of bug #343461
I wonder which version of g++ was used to get the initial compilation error. I can't obtain it here with any of the versions I tried. Bruno, could you please post the g++ version and the command line (including all the flags) used? TIA!
(In reply to comment #14) > I wonder which version of g++ was used to get the initial compilation error. I > can't obtain it here with any of the versions I tried. Bruno, could you please > post the g++ version and the command line (including all the flags) used? TIA! I can no longer reproduce this by reinstalling combinations of i386 and x86_64 wxGTK. There have been a lot of updates since I was failing to build hugin outside of mock (including gcc-c++). The only way I can think of approaching this is with a fresh install of fc8 from the original DVD.
*** This bug has been marked as a duplicate of 343461 ***