[gccsdk] [GCCSDK commit] peter - r4189 - trunk/gcc4

Peter Naulls peter at chocky.org
Sun Nov 8 15:29:57 PST 2009

John Tytgat wrote:
> In message <4AF71A7B.4000308 at chocky.org>
>           Peter Naulls <peter at chocky.org> wrote:
>> I understand where you're coming from.  But in practice env/bin contains
>> mostly things which are used for builds - a lot of it library config
>> scripts, etc.  It does also contain a number of RISC OS binaries,
>> but their presence there is of questionable use.  These are mostly
>> things that are library utilities, and got installed along with them.
> I don't think we should fight common conventions to repurpose
> $PREFIX/bin in builds using cross-compiler by placing native build tools
> there.

I'm not sure you're adequately distinguishing between the different
contents of this directly.  On my setup, there are no less than 80
scripts there, which are used for library configuration purposes.
In fact, I don't think we should be installing RISC OS binaries at all
here, and I'm tempted to modify ro-install to ditch any such binaries
placed here, since they have no purpose.

I disagree that we are "fighting" anything - this is just how it
works out with the extant build systems, many of which know
nothing about cross compilation.

> A 'make install' installs binaries in $PREFIX/bin and those binaries
> are in our case RISC OS ones.  Let's not contaminate that directory with
> host binaries.  We should not have $PREFIX/bin in our PATH during
> Autobuild builds.

It has to be in the path - or something does - to pick up the above
scripts, and occasional binary.

> If someone happens to have qemu activated with the
> binfmt_misc enabled for AOF/ELF binaries, you suddenly going to execute
> those RISC OS binaries during building which will give for sure
> interesting and confusing fallouts.

All RISC OS binaries should end in ,e1f - so unless qemu is somehow
picking these up, I don't see this scenario - in any case, this can
be avoided by not installing the RO binaries in the first place.

> If that's the only reason, let's create an env/bin-cross directory
> holding those native zip/orbit-idl etc binaries and then we avoid
> possible contamination of host and RISC OS binaries and by removing
> $GCCSDK_INSTALL_ENV you can start from a clean state as well.

Well, there are actually other scripts in env itself, and
we could move things there if that was really your objection.  However
enforcing this in general is a bit tricky, although it's only
a couple of cases.

More information about the gcc mailing list