Opened 10 years ago

Closed 10 years ago

#12689 closed build error (fixed)

Mac 10.4 / gcc 4.0 build fails

Reported by: joostn Owned by: csomor
Priority: normal Milestone:
Component: wxOSX Version: stable-latest
Keywords: stl_algo.h arrstr.cpp Cc: joost@…
Blocked By: Blocking: #12691, #12691
Patch: no

Description

Building of an OSX 10.4 version of trunk fails. Configure settings:

export LIBRARY_PATH=/Developer/SDKs/MacOSX10.4u.sdk/usr/lib
export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.4u.sdk/usr/include
export arch_flags="-arch i386 -arch ppc"

../configure --enable-debug --with-macosx-sdk="/Developer/SDKs/MacOSX10.4u.sdk" --with-expat=builtin --enable-unicode --disable-shared --enable-monolithic --enable-universal_binary --disable-compat26 --disable-compat28 --with-osx-cocoa CFLAGS="$arch_flags -mmacosx-version-min=10.4" CXXFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags" --with-macosx-version-min=10.4 CC="gcc-4.0" CXX="g++-4.0" LD="g++-4.0"

This results in the following compile error:

/Developer/wxwtrunk1/trunk/build_10.4_debug/bk-deps g++-4.0 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -c -o monolib_arrstr.o  -D__WXOSX_COCOA__      -DWXBUILDING -I/Developer/wxwtrunk1/trunk/build_10.4_debug/src/tiff/libtiff -I../src/tiff/libtiff -I../src/jpeg -I../src/png  -I../src/regex -I../src/expat/lib -I../src/stc/scintilla/include -I../src/stc/scintilla/src -D__WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_BASE=1 -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 -I/Developer/wxwtrunk1/trunk/build_10.4_debug/lib/wx/include/osx_cocoa-unicode-static-2.9 -I../include -g -O0 -arch ppc -arch i386 -arch x86_64 -arch i386 -arch ppc -fno-common  ../src/common/arrstr.cpp
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/stl_algo.h: In function ‘void std::__final_insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = wxString*, _Compare = wxSortPredicateAdaptor]’:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/stl_algo.h:2608:   instantiated from ‘void std::sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = wxString*, _Compare = wxSortPredicateAdaptor]’
../src/common/arrstr.cpp:418:   instantiated from here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/stl_algo.h:2235: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/stl_algo.h:2235: note: candidate 1: operator+(wxString*, long int) <built-in>
../include/wx/arrstr.h:246: note: candidate 2: wxArrayString::reverse_iterator operator+(const wxArrayString::reverse_iterator&, int)

The same configure settings work fine when compiling wxw2.9.1.

Change History (6)

comment:1 Changed 10 years ago by vadz

This is pretty mysterious, first of all because nothing seems to have changed in this code since 2.9.1 and second because I don't understand at all why does the compiler go looking for the operator+() overload taking reverse_iterator. The type of m_pItems here is wxString * so the normal (built-in) operator should be used.

Anyhow, I think that either adding wxEXPLICIT before reverse_iterator(pointer ptr) ctor (and probably the same for const_reverse_iterator) or explicitly casting m_nCount to long should fix the build. The former would be preferable probably.

Could you please check if this works (and doesn't result in any other problems, e.g. in the test suite) and submit a tested patch if it does?

TIA!

comment:2 Changed 10 years ago by vadz

  • Blocking 12691 added

(In #12691) Unfortunately I can't help with this one, just resetting the patch checkbox.

comment:3 Changed 10 years ago by snowleopard2

Don't know if this is relevant, but I can tell you that GCC 4.0 simply chokes on reverse_iterators. I had code that used a reverse_iterator and GCC 4.0 would get confused when I called operator+= against the iterator. GCC 4.2/Visual Studio had no problem compiling, but GCC 4.0 would fail to compile. When I changed the code to just use a regular (forward) iterator then GCC 4.0 and 4.2 compiled fine.

So my point is: is there somewhere new in WX that is using a reverse_iterator? (I looks like it, judging from the error messages above). If so, maybe that is the culprit.

comment:4 Changed 10 years ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

your wxEXPLICIT for both iterators works, I'll commit and watch the buildbots ...

comment:5 Changed 10 years ago by SC

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [66724]) using explicit fixes #12689

comment:6 Changed 8 years ago by vadz

  • Blocking

(In #12691) We don't support 10.4 any more.

Note: See TracTickets for help on using tickets.