Kai Henningsen <kai.extern@xxxxxxxxx> writes: > On Sat, Oct 23, 2010 at 21:40, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > >> 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. Those are the tools which gcc and other tools need to invoke under certain circumstances. as: for gcc -c ld: for gcc without -c nm: to get the list of required constructors/destructors on some systems objcopy: used with uclinux to generate a FLT binary objdump: likewise Actually I forget why ranlib, ar, and strip are there, but there was a reason for it. > 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. That particular directory is shared with the GNU binutils, which can not install into gcc/$target/4.5.1 because they don't know the gcc version number. > 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'm not wrong. I was there when we chose that directory as a place to install the GNU binutils where gcc could reliably find them under known names. Once we had the directory it made since to put a copy of the gcc driver as well, when it turned out that we needed it. > 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.) That may or may not be a problem with the build system. I always set CC on the configure line when I'm using --build. Ian
