| 1 |
On 2013-04-15 12:10 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 2 |
> Argh. Reply to your own posts if you need to append content. Otherwise, |
| 3 |
> I can't easily address everything at once. |
| 4 |
|
| 5 |
Sorry, I usually do, but I'm kind of flustered right now... |
| 6 |
|
| 7 |
> Anyway, you can (I believe) run a 64-bit kernel with a 32-bit CHOST. |
| 8 |
> Your system is a tad hobbled that way, but it should "work". It'd be |
| 9 |
> like running multilib without the 64-bit side of things. |
| 10 |
|
| 11 |
I went ahead and switched back to the 32bit kernel, updated gcc, |
| 12 |
recompiled openssl/openssh and finally got ssh working again (whew, |
| 13 |
their Lish Web console sucks)... |
| 14 |
|
| 15 |
> Set your CFLAGS on your prod server to that of your dev server, if your |
| 16 |
> dev server is known to work. You're using -march=native on your prod |
| 17 |
> server, which depends on gcc correctly detecting CPU features from the |
| 18 |
> host. There was a thread on this list just a few days ago about how that |
| 19 |
> can fail in virtualized environments. (You can enable/disable exposed |
| 20 |
> features piecemeal, which could well confuse the heck out of gcc's |
| 21 |
> detection heuristics...) |
| 22 |
|
| 23 |
I think I know now - it was glib that got compiled, but not while |
| 24 |
running a 64bit kernel... it must have been the march-native that |
| 25 |
screwed it up. |
| 26 |
|
| 27 |
> I don't know which instruction is 'illegal' on your new host, so, yeah, |
| 28 |
> the safest path is going to be emerging, well, everything. You don't |
| 29 |
> want some --as-needed lib getting pulled in some time down the road, |
| 30 |
> causing a real headscratcher of a crash. As the saying goes[1], "Nuke |
| 31 |
> everything from orbit. It's the only way to be sure." |
| 32 |
|
| 33 |
<snip> |
| 34 |
|
| 35 |
> [1] Where'd that come from, anyway? |
| 36 |
|
| 37 |
Aliens? |
| 38 |
|
| 39 |
Thanks again Michael |
Archives