Re: Bug with cross builds?

[Ian Lance Taylor <iant at google dot com>]

Kai Henningsen <kai.extern@gmail.com> writes:

> On Sat, Oct 23, 2010 at 21:40, Ian Lance Taylor <iant@google.com> 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