On 04/15/2013 11:53 AM, Tanstaafl wrote: > On 2013-04-15 11:42 AM, Michael Mol <mike...@gmail.com> wrote: >> Guessing the new host has different CPU capabilities exposed to the >> guest, either because of a differing hypervisor configuraiton, or >> because of the different underlying hardware. > > Hmmm again... > > CHOST is the same on both: > > CHOST="i686-pc-linux-gnu" >
Argh. Reply to your own posts if you need to append content. Otherwise, I can't easily address everything at once. Anyway, you can (I believe) run a 64-bit kernel with a 32-bit CHOST. Your system is a tad hobbled that way, but it should "work". It'd be like running multilib without the 64-bit side of things. Set your CFLAGS on your prod server to that of your dev server, if your dev server is known to work. You're using -march=native on your prod server, which depends on gcc correctly detecting CPU features from the host. There was a thread on this list just a few days ago about how that can fail in virtualized environments. (You can enable/disable exposed features piecemeal, which could well confuse the heck out of gcc's detection heuristics...) I don't know which instruction is 'illegal' on your new host, so, yeah, the safest path is going to be emerging, well, everything. You don't want some --as-needed lib getting pulled in some time down the road, causing a real headscratcher of a crash. As the saying goes[1], "Nuke everything from orbit. It's the only way to be sure." You might be best served by setting up a new VM from scratch and copying over the bulk of your configuration (USE flags, daemon configurations, etc.). It's certainly something you should look into once you get this VM hobbling along again. [1] Where'd that come from, anyway?
signature.asc
Description: OpenPGP digital signature
