Code::Blocks

User forums => Using Code::Blocks => Topic started by: KirkD on November 24, 2010, 12:53:13 am

Title: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD on November 24, 2010, 12:53:13 am
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.

Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: jens 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: [Select]
    // 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.
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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: [Select]
// 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: [Select]
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.  
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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.
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: jens 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: [Select]
/* 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).
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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

Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: jens 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.

Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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

Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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

Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: jens 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 (http://forums.codeblocks.org/index.php/topic,8755.msg78482.html#msg78482)
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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.

Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: oBFusCATed on December 01, 2010, 06:02:36 pm
Code: [Select]
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 :)
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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.
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: jens 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 .
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD 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.

Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: jens on December 01, 2010, 09:29:35 pm
I have to correct me:
wxWidgets is installe below /usr/lib64 in centos and in fedora14.

wx-config is a softlink to /usr/lib64/wx/config/gtk2-unicode-release-2.8 or /usr/lib/wx/config/gtk2-unicode-release-2.8 or any other configuration, so if you change the link, it should work without that hack.

On fedora it's a wrapper-script, that can be called with the --arch argument to force an arch, without the argument the result of uname -m is used.

Maybe update-alternatives exists for centos (as it does for fedora and debian/ubuntu), to configure /usr/bin/wx-config the "right" way (it does not exist or is not installed on my system).
Title: Re: ambiguous overload for 'operator[]' during compilation of Code::Blocks
Post by: KirkD on December 01, 2010, 09:33:42 pm
Whew! 

That makes more sense now.  At least we're seeing the same type of thing.

Yes, the hack was driving me crazy.  8^(  I've successfully built Code::Blocks on two CentOS 5.5 systems this afternoon with the modified installation of only x86_64 wx libraries.

Thank you for all your help and the discussion.  It seems there is always more to learn in LINUX, eh?

-Kirk