CPU you selected does not support x86-64 instruction set
 

I've searched for this, but nothing on this site turns up. This error seems common in a number of other projects, but I bet someone here has ran into it.

Yes, I'm trying to build on a 64-bit machine. All of my machines have over 4G, and are running 64-bit OS's. I'm sure EQEmu will appreciate some extra RAM.

During the build, these errors come out on stderr:

cc1plus: error: CPU you selected does not support x86-64 instruction set

(That message came during a "make clean").

When I do a regular make I get 97 of these messages before the build
halts during the compile of common/timer.cpp

I have downloaded the source tree from SVN today, so this is on the most recent code base.

Does anyone have a recommendation? I really want to build this from source, as I would like to make some local changes.

What is the output from uname -a?

Linux xxxxxxxxxxxxxxx 2.6.38.8-35.fc15.x86_64 #1 SMP Wed Jul 6 13:58:54 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Ok. If you google for that error you'll see it's generally due to one or more of the packages you have installed. I would go through the prereqs for the server like MySQL, Perl, etc, and make sure they are up to date and installed for the appropriate architecture.

I've googled the error, and it didn't seem to me that there was any consensus on what the cause was. I am leaning towards something in a makefile assuming 32-bits, unless people are building this code in a 64-bit environment.

I did check on the installed software, here are the installed packages matching the prereqs in the linux server guides:

Installed Packages
gcc.x86_64 4.6.0-9.fc15 @anaconda-InstallationRepo-201105131943.x86_64
gcc-c++.x86_64 4.6.0-9.fc15 @anaconda-InstallationRepo-201105131943.x86_64
mysql.x86_64 5.5.14-2.fc15 @anaconda-InstallationRepo-201105131943.x86_64
mysql-devel.x86_64 5.5.14-2.fc15 @updates
mysql-server.x86_64 5.5.14-2.fc15 @anaconda-InstallationRepo-201105131943.x86_64
perl.x86_64 4:5.12.4-159.fc15
@anaconda-InstallationRepo-201105131943.x86_64
perl-IO-stringy.noarch
2.110-15.fc15 @fedora


I believe that perl-IO-stringy is noarch since it is not executable code, but rather PERL. The others are the proper 64-bit versions.

Think I see the problem
 

Nothing to do with installed packages.

The default makefiles build with -march=i686 which is causing all of those errors on my 64-bit system.

In several directories I see makefile.a64, so manually issuing a "make -f makefile.a64" gets me further along.

There was one problem in zone where the PERL_FLAGS were not being used, I modified makefile.a64 to work like makefile in that respect.

There were a few directories with no makefile.a64, so I copied makefile to makefile.a64 and switched the architecture.

Everything builds. There are a ton of warnings for various things that shouldn't hurt (comparison between signed and unsigned).

Of course, since it builds it must run correctly.

I'm interested in hearing comments on the above. If folks are building 64-bit just fine, then I am somehow in the minority and would like to know why. If I am one of a handful doing this, then it would be nice to know who is maintaining the a64 makefiles and discuss changes might make others' have an easier time.

I would also feel a ton better if those warnings were gone, and may clean up my build tree. If there is interest we can discuss getting those changes back into subversion at some point.

Many people are able to compile for 64 bit just fine.

Based on my google search, what you're looking for is something specifying -march, -mcpu, or -mtune with an inappropriate value for 64-bit support.

Here's a likely candidate from the makefile in zone. I didn't check any others.

COPTS=$(WFLAGS) -O -g -march=i686 -pthread -pipe -D_GNU_SOURCE -DINVERSEXY -DFX -DZONE $(DFLAGS) $(MYSQL_FLAGS) $(PERL_FLAGS)

That is pretty much what I just said.

Well, I replied before I saw your post. Good luck with your server.

I changed the -march=686 to -march=athlon64 (I think, been a while) to ensure everything compiled right. Worked like a charm.

Regards,
Mg

another thing you can do is to just install on an i386 version, and then do a apt-get install linux-image-2.6-686-bigmem (if i recall correctly) to utilize more than 4 gigs of ram.

I did get mine to compile, it even ran with no errors. Unfortunately the zones crash as you go in. My database and source are the same as my Debian 32 bit. I ran everything through the command line, and checked the logs and there are no errors, I just get a message that the zone restarted.

There is another message on the forum with other people getting that same "rebooting zone" message that have tried to run x64. Anyone had success ?

It would help to see a stack trace of the crash. Load a core file in gdb and type 'bt'

Is there a way to force it to do a core dump ? The zone appears to be rebooting, but there is never a core dump to debug.

I ended up removing the -O from the makefiles and all is well.

Just for notation, this is vSphere 5, Debian 6 AMD64 build, with a Xeon 8 core processor.

I started actually playing and looking for issues this morning and noticed something. It appears their is a small problem going x64 that I would not had thought would pop up. Guilds are not working. I managed to copy / paste the error.

Doing some reading this has to do with collation sets I guess. I checked and my tables appear to be a mix of latin_swedish_ci and utf8_general. I am not sure what changed or got messed up going from Debian 5 x32 to Debian 6 x64. I did the dump with mysqldump and imported it back in like I would normally do. I am going to go ahead and change this table. What should all of the tables be guys ? utf8 right ?

Well I got it by converting it all to UTF8 with HeidiSQL using the bulk editor. Not sure if this will cause a problem in the future, maybe someone with more MySQL can answer that. Strange thing though, Heidi converted one of the views into a table so I had to recreate the guild view.