After discussing gcc versions with Chris Rutter at the UK Linux Expo I decided to give gcc 2.95 a whirl with binutils-2.9.5.0.14. I wanted to build it completely from scratch rather than use any part of my previous egcs-1.1.2+philb patches install so I needed to use the inhibit_libc/threads hack but gcc appeared to compile and install correctly - my usual method of not bothering to do this but using the fact that enough of the compiler was actually built by the time it bombed out doesn't seem to work anymore :-( It seems that quite a lot of stuff has changed and I was first worried by the following message when I tried to configure glibc-2.1.2. checking for ld --version-script... no *** WARNING: You should not compile GNU libc without versioning. Not using *** versioning will introduce incompatibilities so that old binaries *** will not run anymore. *** For versioning you need recent binutils (binutils-2.8.1.0.23 or newer). The config.log contains: configure:2312: checking for ld --version-script configure:2335: arm-empeg-linux-gcc -shared -o conftest.so conftest.o -nostartfiles -nostdlib -Wl,- -version-script,conftest.map 1>&5 /home/mac/empeg-nocvs/gcc295/arm-empeg-linux/bin/ld: cannot represent machine `arm:amachine.adomain' collect2: ld returned 1 exit status It seems that ld is failing rather than the --version-script causing a problem. I had a look at the scripts in target/lib/ldscripts and all the _linux ones seem to contain the output architecture defined as arm:FQDN. I looked at the equivalent directory for egcs-1.1.2 and everything seems to have changed rather a lot but all the files just mentioned an output architecture of arm. Is this arm:FQDN stuff correct? Should I be looking elsewhere for the root of the problem? Also, once I do persuade this to work I assume I have to go right back to the beginning and compile without the inhibit_libc/threads hack and then compile glibc again to get threads support. TIA -- Mike Crowe unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
