Ok, I found what might be the cause.
In the first time I ran this command:
Code:
for file in \
$(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
do
cp -uv $file{,.orig}
sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
-e 's@/usr@/tools@g' $file.orig > $file
echo '
#undef STANDARD_STARTFILE_PREFIX_1
#undef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
touch $file.orig
done
I typed every character by hand, and I made a mistake in "$file{,.orig}" because I typed "$file{, .orig}" and I got some strange outputs from sed saying that it coudn't locate the files. So I ran it again but I copied and pasted it instead of typing by hand, and everything looked ok.
So, an interesting thing is that when I got the error from "make", I tried to fix it by removing "gcc-build" dir, creating it again and starting from there.
But then, after HOURS trying to fix this, I simply removed gcc-4.9.2 and started again from unpacking gcc-4.9.2.tar.bz2. Then things just worked.
So, my conclusion is: the cause of the problem was probably my first run of the above command in which I typed a space where shoudn't be one. But something I also noticed was the fact that I was using /bin/dash when I ran all of this because I changed /bin/sh but didn't close the terminal session, so I ran the commands with dash, resulting in a possible different behavior of the command (I have no idea if that makes sense).
So, all this trouble was probably caused by: a space character, or the great idea of changing /bin/sh but continue to use the same gnome-terminal session.
Solution
