On Thursday 17 April 2008 00:42, Daniel Jacobowitz wrote: > On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote: > > It seems that 4.2.1 was testing "/usr/lib/../x86_64-linux-uclibc/include", > > i.e. "$libdir/../x86_64-linux-uclibc/include". From the listing above > > I see them 4.3.0 does not do that anymore - there is no > > "/../x86_64-linux-uclibc/include"... or maybe there is, in the form of: > > "xxx/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include" > > Correct. A relocated GCC 4.2.1 installation would still search > various directories in their unrelocated paths. This was a bug and > I'm sorry to hear that fixing it broke your setup. It could cause all > sorts of problems when you have two versions of GCC installed.
I believe I solved it with --with-sysroot, and then met yet another problem: 4.3.0 tried to link in different crtXXX.o files (those which do not exist on my system). Will try again and let you know. > The documented (well, I think it is?) directory being searched here is > $exec_prefix/$target/include. > > > (Is it necessary to do this "/../../../../" thing?) > > Yes, because that's how the directories are found. Well, it looks like the path like "xxx/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include" is equivalent to simply "xxx/x86_64-linux-uclibc/include", sans cases where one of those directories (which we go into only to go out again) does not exist. Hmm. Maybe symlinks may make it more complex. Oh well. -- vda
