Bug 295521 - -fno-strict-aliasing breaks hugin build
-fno-strict-aliasing breaks hugin build
Status: CLOSED DUPLICATE of bug 343461
Product: Fedora
Classification: Fedora
Component: wxGTK (Show other bugs)
7
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Matthew Miller
Fedora Extras Quality Assurance
:
Depends On:
Blocks: CVE-2007-5200
  Show dependency treegraph
 
Reported: 2007-09-18 17:30 EDT by Bruno Postle
Modified: 2008-02-20 16:14 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-20 16:14:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Postle 2007-09-18 17:30:56 EDT
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.
Comment 1 Matthew Miller 2007-09-18 20:38:24 EDT
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.
Comment 2 Bruno Postle 2007-09-19 05:01:58 EDT
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.
Comment 3 Matthew Miller 2007-09-19 07:00:32 EDT
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]?
Comment 4 Bruno Postle 2007-09-19 17:25:21 EDT
(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.
Comment 5 Bruno Postle 2007-09-21 05:51:38 EDT
(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.
Comment 6 Matthew Miller 2007-09-21 07:00:08 EDT
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.
Comment 7 Matthew Miller 2007-09-21 08:38:28 EDT
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.
Comment 8 Bruno Postle 2007-09-21 17:57:10 EDT
(In reply to comment #7)

I'd be out of my depth, I can't speak with any authority about what this problem is.
Comment 9 Lubomir Kundrak 2007-11-01 12:35:19 EDT
Matthew: Please do rebuild the updated packages as soon as you can. This his
holding build of a security fix. Thanks!
Comment 10 Matthew Miller 2007-11-01 12:44:19 EDT
Busy this afternoon. Tonight or tomorrow.
Comment 11 Paul Johnson 2007-11-15 23:43:28 EST
I can't find these new RPMS for wxGTK anywhere. Were they made & released?
Comment 12 Bruno Postle 2007-11-16 05:52:30 EST
(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.
Comment 13 Bruno Postle 2007-11-19 16:53:30 EST
(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
Comment 14 Vadim Zeitlin 2007-11-20 17:18:01 EST
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!
Comment 15 Bruno Postle 2007-12-04 16:44:47 EST
(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.
Comment 16 Matthew Miller 2008-02-20 16:14:57 EST

*** This bug has been marked as a duplicate of 343461 ***

Note You need to log in before you can comment on or make changes to this bug.