Author Topic: ambiguous overload for 'operator[]' during compilation of Code::Blocks  (Read 15223 times)

Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
I just pulled down the latest SVN for Code::Blocks (6857) and have started building it on a 64-bit CentOS box.  I've gotten a number of errors of this sort during build:

uservarmanager.cpp: In member function 'void UsrGlblMgrEditDialog::Sanitise(wxString&)':
uservarmanager.cpp:120: error: ambiguous overload for 'operator[]' in 's'
uservarmanager.cpp:120: 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)

The first was associated with /usr/include/wx-2.8/wx/filename.h and I found the fix was to change the [0u] in line 393 to [(size_t)0u].

Now, I've gotten the same error for for /src/sdk/cbeditor.cpp and also /src/sdk/uservarmanager.cpp (above).  I'm hoping there's a compiler switch that can be set to let this go, but I have yet to find it.

Any tips are appreciated.

-Kirk

As I'm looking a little closer I see that I could probably get the same result by converting to (int) rather than (size_t).   The index to the wx string::operator[] is a long int, but the operator function expects either size_t or int.

UPDATE:  I can get this error to pass if I set CXXFLAGS and CFLAGS to -m32 prior to running ./configure.  I then get errors due to 32-bit vs. 64-bit GCC libraries.  I haven't yet tried pushing the 32-bit libraries.

« Last Edit: November 24, 2010, 01:41:17 am by KirkD »

Online Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #1 on: November 24, 2010, 07:58:12 am »
Where did you get your wyWidgets from.

There should be a a third overload for operator[] in string.h (and array.h), if size_t is not unsigned int:
Code
    // operator versions of GetWriteableChar()
    wxChar& operator[](int n)
      { return wxStringBase::at(n); }
    wxChar& operator[](size_type n)
      { return wxStringBase::at(n); }
#ifndef wxSIZE_T_IS_UINT
    wxChar& operator[](unsigned int n)
      { return wxStringBase::at(n); }
#endif // size_t != unsigned int

So I think our code should be valid in any cases.

Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #2 on: November 24, 2010, 07:51:20 pm »
The wxWidgets that I am using is a package associated with CentOS 5.5, x86_64.  It may have come from rpmfusion, but I'm not certain of that.  It is version 2.8.11, the current stable release from wxWidgets.

The odd part is that the original error arose from one of wx's own source files - /usr/include/wx-2.8/wx/filename.h.  I found the fix to this through a simple Google search - described in my first post.

I looked into the wx string.h file and I see the same code section that you posted, specifically

Code
// operator versions of GetWriteableChar()
    wxChar& operator[](int n)
      { return wxStringBase::at(n); }
    wxChar& operator[](size_type n)
      { return wxStringBase::at(n); }
#ifndef wxSIZE_T_IS_UINT
    wxChar& operator[](unsigned int n)
      { return wxStringBase::at(n); }
#endif // size_t != unsigned int

I'm compiling with GCC 4.4.5 - not sure if that has any impact as I didn't check to see how or where wxSIZE_T_IS_UINT is or isn't defined.

The alternative that I am just beginning to try is to add another function to string.h:

Code
wxChar& operator[](long n)
{ return wxStringBase::at(n); }
wxChar& operator[](unsigned int n)
{ return wxStringBase::at(n); }
Seems easier that changing all the instances where a long is passed in the Code::Blocks source.



Edit:

This seemed to fix the symptom and Code::Blocks is compiling nicely now.  I'm unsure as to why this should occur to begin with.  I haven't dug deep into the wx code or addressed that community just yet - that is my next task.  From what I can find, this is a 64-bit issue, but again, I can't wrap my head around why it should be an issue.  It seems that long, unsigned int, and size_t are all expected to exist as different function signatures.

Edit:  

I verified that my wx package came from the epel repo, the Fedora/RedHat Enterprise Linux repository.  
« Last Edit: November 24, 2010, 08:42:59 pm by KirkD »

Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #3 on: November 24, 2010, 09:48:15 pm »
Interestingly, I just tried the same process on a Fedora 14 x86_64 installation and the code change was not necessary. The same version of wxWidgets (v2.8.11) is present. GCC v4.1.2 is on that system.

Online Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #4 on: November 24, 2010, 10:40:41 pm »
I tried it on CentOs 5.5 with wxGTK 2.8.10 from rpmforge and it works fine.
You can look into /usr/lib64/wx/include/gtk2-unicode-release-2.8/wx/setup.h to see whether wxSIZE_T_IS_UINT is defined or not.
It should be:
Code
/* Define if size_t on your machine is the same type as unsigned int. */
/* #undef wxSIZE_T_IS_UINT */

/* Define if size_t on your machine is the same type as unsigned long. */
#define wxSIZE_T_IS_ULONG 1
on 64-bit systems.
It looks like the package is not configured or build correctly or the setup.h is from a 32-bit build (or a build on a 32-bit machine).

Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #5 on: November 24, 2010, 11:05:02 pm »
I checked the file you mentioned, and it is as you listed.  I'm not sure what is going on here, but I've had the same results on two different CentOS 5.5 x86_64 installs with wxGTK 2.8.11.  My modification seems to fix the problem, so it isn't an issue with respect to Code::Blocks at this point.  I also have a question out to the wxWidgets community - I'll post back here any response I get.  My guess is that the package was built incorrectly or there is (yet another) CentOS problem.

Thank you for your help.

-Kirk


Online Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #6 on: November 24, 2010, 11:46:25 pm »
There might be multiple setup.h's on your system.

If you run wx-config --cppflags in a console you should be able to see the base-path of the setup.h used as default.
It's one of the include-directories, and it's the one that starts with /usr/lib[32|64].
If you just add /wx/setup.h to it, you know which setup.h is actually used.


Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #7 on: November 29, 2010, 07:33:27 pm »
Jens,

I apologize for the slow reply - holiday weekend.

I checked wx-config --cppflags as you suggested, and you are correct.  I have two setup.h files on the system, one in /usr/lib64 one in /usr/lib.  It seems that a standard package installation brings along both 32-bit and 64-bit versions simultaneously.  The default is apparently referring to the 32-bit version and not the 64-bit version.

At this point I was able to get it built using my (hacked) modifications - I don't anticipate it will cause a problem.  But, I'll give it another try on a test machine (virtual) to see if I can reliably fix it.

Thank you for the assistance!

-Kirk


Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #8 on: December 01, 2010, 12:57:47 am »
I've been working this a bit further and I cannot seem to force the build process to look at the correct (lib64) setup.h file.  I've tried the various settings for configure with no luck.

Regarding wx on CentOS, when I install wxBase, it comes along with both the x86_64 version and the i386 version.  If I remove the i386 version, wx-config is also removed despite the x86_64 version still being present. 

I can go in and manually change the setup.h file for the 32-bit version, but that seems a bit of a hack.

I realize that I'm splitting hairs here for "correctness", but if anyone has tips on making this behave as expected, please let me know.

-Kirk


Online Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #9 on: December 01, 2010, 08:02:08 am »
If I remember correctly its is not allowed to have 32-bit libs in the lib-folder on 64-bit systems.
As far as I know, the standard only allows to use lib for native libraries (32-bit on 32-bit and 64-bit on 64-bit systems).
lib32 and lib64 are allowed for thw appropriate type of libs.
That's the cause, why C::B first looks into lib and if it does not find it's plugins, it looks into lib64.

I use wxGTK from rpmforge on centos and I have no such issues. So I think either the repo you use has a broken wxGTK version or anything other went wrong.

See also my post here: http://forums.codeblocks.org/index.php/topic,8755.msg78482.html#msg78482

Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #10 on: December 01, 2010, 05:43:58 pm »
Jens,

I'm not sure if I agree with you regarding 32-bit and 64-bit.  I thought /usr/lib was where 32-bit libraries lived and /usr/lib64 was where 64-bit libraries lived.  There is often an option to install both 32 and 64 bit libraries upon install.  For whatever reason, the epel repository installs both 32- and 64-bit for most packages on my system.  I also remember that most 32-bit apps can be run on 64-bit systems if the right compatibility libraries are available.

Regardless, in my case if I don't install the 32-bit version of the libraries, I don't get wx-config.  Now I'm trying to figure out how to force wx-config to give the right include directory, specifically, the 64-bit version.  Again, it is kind of a minor point as I can make the previously mentioned modifications to wx's string.h or I can even modify the setup.h to have the proper definition.  Either of these works, I just feel dirty for doing it.  8^)

I'll double check regarding the 64- and 32-bit library locations and post back what I find.


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #11 on: December 01, 2010, 06:02:36 pm »
Code
obfuscated@xlad ~ $ ls -l /usr/lib
lrwxrwxrwx 1 root root 5 26 я▌п╩п╦  2008 /usr/lib -> lib64
He is correct :) or my gentoo amd64 system is broken :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #12 on: December 01, 2010, 06:05:19 pm »
Jens is correct?  It would not surprise me at all if CentOS is the one that is broken.  I just check and on my standard CentOS install, /usr/lib and /usr/lib64 are distinct directories with different contents.  Same for Fedora 14, but on the Fedora 14 install, when I install wx I only get the 64-bit version and wx-config --cxxflags points to the right location.
« Last Edit: December 01, 2010, 06:08:10 pm by KirkD »

Online Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #13 on: December 01, 2010, 07:46:42 pm »
Did you read the post I linked against ?
I still think /usr/lib is for the native libs.

On my centos installation I have no such problems and my 64-bit wxWidgets from rpmforge is installed below /usr/lib .

Offline KirkD

  • Multiple posting newcomer
  • *
  • Posts: 77
Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
« Reply #14 on: December 01, 2010, 08:27:48 pm »
Yes, I read the thread you posted.  I'm not doubting that what you suggest is how things should be configured, I'm just pointing out that I don't see exactly that in my experience.

On my Fedora 14 installation, when I execute yum install wx*, only the x86-64 versions are installed, and they all (code and shared object libraries) reside in /usr/lib64.  There are no traces of anything wx in usr/lib.  On my CentOS 5.5 installation, the same command causes both versions to be installed, hence the problem.  If I go back and remove all traces of wx, and then install only the 64-bit versions, I see the same result as in Fedora with nothing wx under /usr/lib.  Also, I have never seen /usr/lib32, but rather it seems that /usr/lib behaves as /usr/lib32.

Regardless of our different experiences and perceptions, the root of the problem is that the epel repository gives me both 32- and 64-bit versions when it probably should only give me the 64-bit version.  If I manually force only the 64-bit versions to be resident, the problem is solved.