The absence of /lib/ld-linux.so.1 causes bash to output "bash: ../../mips-x86.linux-xgcc/gcc: No such file or directory" when I try executing an old cross compiler binary. Doing a symbolic link to /lib/ld-linux.so.2 fixes it. That is a very nasty error message that is hard to diagnose unless you know what you are doing. Would it be possible to have sys-libs/glibc install /lib/ld-linux.so.1 as a symbolic link to /lib/ld-linux.so.2 for compatibility purposes?
I just discovered that lib-compat provides this file. Unfortunately, I get "gcc: virtual memory exhausted" when I try running "../../mips-x86.linux-xgcc/gcc -v". Doing the following fixes it: rm /lib/ld-linux.so.1 ln -s /lib/ld-linux.so.2 /lib/ld-linux.so.1 I will update the summary to reflect this. Is there any reason why /lib/ld-linux.so.1 should not be a symbolic link to /lib/ld-linux.so.2?
Given there was an major version library bump, there probably was a good reason not to do it. But you're free to break your system as much as you like.
(In reply to comment #2) > Given there was an major version library bump, there probably was a good reason > not to do it. > > But you're free to break your system as much as you like. > I am still getting virtual memory exhausted errors with ld-linux.so.2, except they do not occur on small problem sizes. My latest thinking on this is that something changed in a recent kernel version to break things. I am going to test that theory some time today by going back to an older kernel.
The combination of Linux 2.6.35.8 and a few other things made things work again. I think that this program was compiled under CentOS, which is why it requires a very exotic configuration to run properly. Another version of the binaries is available for FreeBSD, so I am in the process of setting up a FreeBSD virtual machine to avoid having to do weird things to my laptop to keep this software running. If it doesn't work, I will move to CentOS and hopefully be able to run them.
