This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix unified tree breakage


On Oct  6, 2005, Paolo Bonzini <bonzini@gnu.org> wrote:

> The stage2 and stage3 binaries should be identical (and even the
> stage1 and stage2 binaries should behave the same).  Thus, using the
> previous stage of the in-tree assembler/linker could even be correct,
> but it is not what it is done.

Except for the stage1 case, that's exactly where relying on the
previous stage's assembler/linker could cause things to fall apart.

Anyhow, good to know it's not broken.

That said, the other day I ran into another recent breakage in a
unified tree: gas/as-new is *hard-linked* to gcc/as, as opposed to
being symlinked.  This means that, if I modify the gas sources and
rebuild them, gcc will still use the old assembler.  Oops.

Ditto for linker and binutils.

If hard-linking is a must for whatever reason (such as simplifying
stage pushing and popping), then we must add dependencies to make sure
these binaries remain up to date with respect to what they were
hard-linked to.

> run-tool --target='$$r/$(HOST_SUBDIR)/gas/as-new' \
>           --target='$$r/$(HOST_SUBDIR)/gcc/as' \
>           --host='$(AS)' \
>           '$(CONFIGURED_AS_FOR_TARGET)'"

> finds an in-tree target assembler, falling back to the system host
> assembler in a native configuration (target = host) or then to the
> $(CONFIGURED_AS_FOR_TARGET).

Neat.

> The first parameter specifies the desired triplet for the tool, so
> --host is only considered if the host and target triplets are
> identical.

I think you need some means to avoid running the wrong binary in
Canadian crosses and cross-back tools.  E.g., consider --build=x
--host=y --target=z.  How can run-tool --target=whatever distinguish
between gas/as-new, that's built for the host y and thus won't run on
the build machine x, from gcc/as, presumably copied from a pre-build
--host=x --target=z toolchain, specified in
$(CONFIGURED_AS_FOR_TARGET), or, as a potential nice improvement,
built in the build-x directory.

And then there's --build=x --host=y --target=x, for which you *could*
use the system assembler.

Just something to think about :-)

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]