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
/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&
/usr/include/wx-2.8/wx/string.h:824: note: wxChar&
See this thread: http://thread.gmane.org/gmane.comp.misc.ptx/7266
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. compile hugin, fails
2. rebuild wxGTK without -fno-strict-aliasing
3. compile hugin, ok
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
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
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  or [static_cast<size_t>(0)] instead of [0u]?
(I tried building hugin with -no-strict-aliasing, but this made no difference,
However I changed wx/filename.h:393 from [0u] to  as you suggest and hugin
now builds ok.
(In reply to comment #4)
> However I changed wx/filename.h:393 from [0u] to  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
(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 ***