On 2013-04-15 12:10 PM, Michael Mol <mike...@gmail.com> wrote:
Argh. Reply to your own posts if you need to append content. Otherwise, I can't easily address everything at once.
Sorry, I usually do, but I'm kind of flustered right now...
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.
I went ahead and switched back to the 32bit kernel, updated gcc, recompiled openssl/openssh and finally got ssh working again (whew, their Lish Web console sucks)...
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 think I know now - it was glib that got compiled, but not while running a 64bit kernel... it must have been the march-native that screwed it up.
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."
<snip>
[1] Where'd that come from, anyway?
Aliens? Thanks again Michael
