On 10/24/08 07:29, Stefan Teleman wrote:
>
>
> Darren J Moffat wrote:
>
>> This is on the assumption that GNU binutils 4.3.x is NOT incompatible
>> with the gcc we currently ship. If GNU binutils *is* incompatible
>> with the gcc we currently ship then IMO this case needs to wait and
>> be part of a future case that upgrade gcc as well, otherwise I don't
>> see the point in shipping the newer binutils if we ship the older
>> compiler (unless the newer binutils are compatible with the compiler
>> we ship).
>
> For the record: I am *purposely* introducing binutils _first_.
>
> When building GCC, its ./configure needs to be told (amongst other
> things):
>
> --with-as=<path-to-the-assembler-executable>
> --with-gnu-as=[yes|no]
> --with-ld=<path-to-the-link-editor-executable>
> --with-gnu-ld=[yes|no]
>
> The values passed in to these two ./configure arguments will be
> written to a dynamically generated header file named auto-host.h:
>
> #define DEFAULT_ASSEMBLER "/usr/ccs/bin/as"
>
> #define DEFAULT_LINKER "/usr/ccs/bin/ld"
>
> /* etc etc etc */
>
> This file is re-generated every time gcc is being rebuilt (which
> amounts to 3 times).
>
> If you require that binutils and gcc be introduced at the same time,
> you have implicitly and explicitly created an assembler location
> problem: the new GNU as is not yet installed on the system, it only
> exists in the proto area. Therefore the path to the new GNU assembler
> will look something like this:
>
> /builds2/steleman/ws/sfwnv-gcc4/proto/root_i386/usr/gcc4/bin/gas
>
> This is the path of the gnu assembler the newly built GCC will look
> for, when installed. Needless to say, this path won't exist on a
> Solaris system. Therefore, GCC won't work, because the assembler it is
> looking for isn't there.
>
> This problem doesn't exist on SPARC (because on SPARC, GCC is
> configured to use /usr/ccs/bin/as, which is already there), but it
> does exist on x86.
>
> One could argue that this path should be replaced with the path to an
> existing assembler. My answer to that is no, the new GCC must build
> itself with the assembler it will use after it is installed, and not
> with some other random assembler. This is simply a sanity check.
>
> Therefore, binutils *must* be integrated, and must be installed on the
> target system before GCC can be built.
Your confusing "build dependencies" with "delivery". How you build the
bits doesn't matter, but IMO, if these bits are required for a certain
GCC version, then you should probably *deliver* both the GCC version and
the binutils at the same time.
How you arrange to build the bits to make this happen is not
architecturally relevant, as long as the final delivered bits don't have
any unresolved dependencies.
-- Garrett
>
> --Stefan
>
