Bug 295521 - -fno-strict-aliasing breaks hugin build
Summary: -fno-strict-aliasing breaks hugin build
Status: CLOSED DUPLICATE of bug 343461
Alias: None
Product: Fedora
Classification: Fedora
Component: wxGTK
Version: 7
Hardware: All
OS: Linux
medium
urgent
Target Milestone: ---
Assignee: Matthew Miller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: CVE-2007-5200
TreeView+ depends on / blocked
 
Reported: 2007-09-18 21:30 UTC by Bruno Postle
Modified: 2008-02-20 21:14 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2008-02-20 21:14:57 UTC


Attachments (Terms of Use)

Description Bruno Postle 2007-09-18 21:30:56 UTC
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-19 00:38:24 UTC
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 09:01:58 UTC
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 11:00:32 UTC
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 21:25:21 UTC
(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 09:51:38 UTC
(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 11:00:08 UTC
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 12:38:28 UTC
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 21:57:10 UTC
(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 16:35:19 UTC
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 16:44:19 UTC
Busy this afternoon. Tonight or tomorrow.

Comment 11 Paul Johnson 2007-11-16 04:43:28 UTC
I can't find these new RPMS for wxGTK anywhere. Were they made & released?

Comment 12 Bruno Postle 2007-11-16 10:52:30 UTC
(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 21:53:30 UTC
(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 22:18:01 UTC
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 21:44:47 UTC
(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 21:14:57 UTC

*** 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.