On Sat, Oct 23, 2010 at 21:40, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > Kai Henningsen <kai.extern@xxxxxxxxx> writes: > >> When building a cross compiler, gcc gets installed at least twice, >> once as $prefix/bin/$target-gcc (long) and once as >> $prefix/$target/bin/gcc (short name), with byte-for-byte identical >> executables. > > This is normal. > >> There does not seem to b a problem with the long-name variant. >> However, the short-name variant cannot seem to find it's own >> components (cc1, -lgcc, and so on). > > This is normal. > >> I seem to recall that this used to >> work (and that compiling something for target was easiest done >> prepending $prefix/$target/bin to $PATH and then configuring and >> building as if non-cross). > > No. ÂThe binaries in $prefix/$target/bin are not expected to work and > you should not put that directory on your PATH. ÂIt's possible that from > time to time they do work, but that is not guaranteed. > > That directory and those files exist so that gcc can reinvoke itself in > certain unusual cases under a known name. ÂWhen it does reinvoke itself, > it passes the environment variables and command line options required to > make everything work correctly. > > (The cases where gcc reinvokes itself are when it needs to compile code > at link time, as is required for global constructor/destructors on > certain targets and for template instantiation when using -frepo in some > cases.) If that is the reason, then why are there similar executables for ar, as, ld, nm, objcopy, objdump, ranlib, ans strip? That does not seem to make sense. For that matter, why would gcc need that copy in that strange place (and not in $prefix/libexec/gcc/$target/4.5.1, where it puts other executables needed internally)? If that bin directory is not supposed to be in a path, then I cannot see why it would be a preferrable location. I suspect that you are wrong, that this copy actually has actually nothing to do with special link-time needs, and that instead this stuff broke as a side effect of removing the old invoke-a-different-version mechanism (I can't even remember what the option was for that). I can say that the problem is in the -print-search-dirs path lists. It can be partially solved (so that compilation works, but linking still breaks) by symlinking $prefix/libexec to $prefix/$target/libexec, or else by replacing $prefix/$target/bin/gcc by a symlink to $prefix/bin/$target-gcc. (*Should* that latter action change the path lists used by gcc? (And if so, why doesn't it change the paths used for linking? Or maybe it changes them, but not in the right way? Neither seems right.)) Anyway, it seems that I need an executable named gcc in my path that compiles to $target, because compiling binutils seems to want to invoke it (that's where I first noticed the problem) when configured with --build=$build --host=$target --target=$target, even though it certainly finds and uses the long-name version. (Feels like a bug, too, but I don't understand the binutils build process well enough. I seem to recall this broke when linking, but I don't remember the details - missing libs or wrong object format.) Or maybe the problems are related to --with-sysroot? Though none of the problematic paths involve the sysroot, and I was under the impression that that was the current most-approved cross build method. Kai
