If I run ldd -v as on my system, I get:
./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as)
linux-vdso.so.1 => (0x00007fff89ab1000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000)
So yeah, it looks like these binaries are looking for a GLIBC_2.14 symbol, which you are presumably missing on your system. As svenx pointed out, it looks like it's searching for the memcpy@@GLIBC_2.14 symbol. Some more information on why memcpy was given a new version is described in this bug report.
Installing a new version of glibc on your target system should fix it. If you want to try to rebuild the binary to still work on the old version of glibc, you could try tricks like the one listed here. You could also maybe get by with a shim that just provides the specific version of the memcpy symbol that you need, but that gets to be a bit hacky.
After reading your update: you're right, that wasn't your problem. But I think I've found it: your binary is requesting the interpreter /lib/ld-linux-x86-64.so.2, which doesn't exist on Ubuntu 12.04 systems:
$ readelf -a ./as | grep interpreter
[Requesting program interpreter: /lib/ld-linux-x86-64.so.2]
While ldd knew to find it in /lib64 instead, I suppose the kernel doesn't know that when it tries to run the binary and can't find the file's requested interpreter. You could try just running it through the interpreter manually:
$ pwd
/home/jim/mingw64/x86_64-w64-mingw32/bin
$ ./as --version
-bash: ./as: No such file or directory
$ /lib64/ld-linux-x86-64.so.2 ./as --version
GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.
I'm not 100% certain this is working correctly -- on my system, running gcc this way gives a segmentation fault. But that's at least a different problem.
On Linux, ps reports kernel threads in square brackets. These are not "processes" in the normal sense of that word. That is, there is not an executable loaded from disk to start them, they aren't owned by a normal user, etc. They're just one of the many things the kernel has going on in the background.
For that reason, the name shown by ps doesn't have to correspond to any file on your hard disk. (In the case of zombie processes, though, it does.)
Best Answer
Debian and Ubuntu are moving to a new multiarch implementation (spec). Among other things, this involves moving arch-specific libraries into
/usr/lib/<triplet>, dropping the limitations oflib32andlib64(where will the new x32 ABI go? where doqemulated binaries live? etc.) as well as extending the package manager to handle mixed-architecture installations much more sanely.