User forums > Using Code::Blocks

ambiguous overload for 'operator[]' during compilation of Code::Blocks

<< < (3/4) > >>

KirkD:
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.

oBFusCATed:

--- Code: ---obfuscated@xlad ~ $ ls -l /usr/lib
lrwxrwxrwx 1 root root 5 26 я▌п╩п╦  2008 /usr/lib -> lib64

--- End code ---
He is correct :) or my gentoo amd64 system is broken :)

KirkD:
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.

Jenna:
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 .

KirkD:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page