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