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

John Tytgat John.Tytgat at aaug.net
Sun Nov 8 14:48:18 PST 2009

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

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.  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.

> Finally, there are a couple of native binaries used for cross build
> config - stuff like orbit-idl-2.   The reason I also put 'zip' here
> is that it's build as part of the autobuilder.  I wanted to keep
> cross/bin entirely for stuff built by the gcc4 tree.  It makes certain
> clean builds and stuff easier, since you can remove each directory
> independently.

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.

That's an approach I can live with.

> I appreciate that there's something of a circular dependency here,
> in that the packaging of GCC requires zip.

A logical solution for this would be to build the RISC OS compiler
using Autobuilder (probably in a mode disabling all the scripts in
$GCCSDK_INSTALL_ENV).  Tbh, I don't think this has a priority as we
have a working solution now and I don't see any gains changing it
nor solution for a problem we would have now.

> However, in practice
> it will also require 'make' (the RISC OS binary) and perhaps other
> stuff we choose to package with the !GCC app.

No, that is a different thing : we were talking about a host binary
which is installed in a wrong directory, not a RISC OS binary which
might or might not need to be part of !GCC.  Aside: I think it should
not be part of !GCC but made separately available like also the binutils
and take care all those packages are easily downloadable.

Don't know whether it is possible to create a metapackage for developing
on RISC OS but that could be useful to address this.

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list