I've recently tried gcc 4.3.2 against uClibc (0.9.28.3). I remember Robert supplying a specs_x86 patch for the gcc-4.1 series, so I decided to port as much of it over to gcc-4.3. While I was doing it, I just could not help but get annoyed at the unportability of gcc's concept of hard coding this stuff in. So, I decided to make an initial attempt at removing some of the hard coding.
I started with Robert's specs_x86 patch and tweaked or changed from there on. The following configure options are supplied by the new patch I made: --with-dynamic-linker-prefix= --with-nostdinc This has been applied to all architectures I could find and should therefore be portable. Previously, with Roberts patch the --with-dynamic-linker= would have to be something like: --with-dynamic-linker=/lib/ld-uClibc.so.0 With my patch it gets broken up into: --with-dynamic-linker-prefix=/lib The ideal situation is to also have the --with-dynamic-linker command: During the toolchain build stage this would be : --with-dynamic-linker-prefix=/tools/lib --with-dynamic-linker=ld-uClibc.so.0 --with-nostdinc and for the glibc: --with-dynamic-linker-prefix=/tools/lib --with-dynamic-linker=ld-linux.so.2 --with-nostdinc But for the moment, there are still sticky cases where both ld.so and ld64.so are supplied. I would rather confirm the stability of the current patch before adding the --with-dynamic-linker= option Let me know if and where I should send the patch for viewing. Thoughts, opinions, criticism, decisions, anyone? -- Kevin Day -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page