On Sun, Oct 24, 2010 at 01:30, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > 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. Um. I almost hate to ask, but (a) how is $prefix/$target/bin/$name any more predictable than $prefix/bin/$target-$name; and (b) why can't I seem to find that one for non-cross compilers? >> 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. Given how many tools there are, and that I'm unconvinced packages will reliably use such variables for all of them, I think I'll set up a directory with shell scripts somewhere. I seem to recall that's how gcc does it at least some of the time, though I don't recall the details.
