installation path for cross compiler

[Ralf Corsepius]

On Thu, 2006-06-22 at 08:57 +0200, Erwin Rol wrote:
> On Thu, 2006-06-22 at 08:45 +0200, Ralf Corsepius wrote:
> > On Thu, 2006-06-22 at 08:26 +0200, Erwin Rol wrote:
> > > Hey all,
> > > 
> > > what would be the correct installation path for a cross-compiler and
> > > it's support include files and libraries ?
> > --prefix=/usr
> > 
> > > For example a arm-unknown-linux-gnu-* toolset, this would include gcc,
> > > binutils, include files, but also libraries compiled for the target
> > > (which of course can not be used on the host and should not be mixed up
> > > with the host libraries)
> > > 
> > > Should that go under something
> > > like /opt/crosscompiler/arm-unknown-linux-gnu/
> > Nope, /opt is outside of Fedora's business. It's reserved for add-on
> > packages outside of a distribution.
> > 
> > > or something like 
> > > /usr/lib/crosstools/arm-unknown-linux-gnu/  because there is also
> > > a /usr/lib/gcc/<arch>/ or 
> > > /usr/arm-unknown-linux-gnu/ or somewhere completely different ?
> > Nope. The package must fold into the /usr* hierarchy.
> > 
> > > Locally i most of the time use some /opt/blabla/ setup, but I don#t
> > > think official distribution packages belong in that place, at least
> > > that's how I understand the Filesystem Hierarchy Standard.
> > Exactly.
> > 
> > That's why we are packaging the RTEMS toolchains with
> > --prefix=/opt/rtems for the rtems.org supplied toolchains but are trying
> > to install them into --prefix=/usr for FE.
> 
> And where are you trying to install things :-) just /usr/include
> and /usr/lib are not really usable,
Depends on what you mean. With the exception of some bugs in
binutils/GCC/gdb bogusly installing files to /usr/include and /usr/lib,
the GNU cross toolchains fold smoothly into the /usr hierarchy and do
not install files into /usr/{lib|include}.

>  and where do the binaries go ?
Host or target binaries.

Host binaries: /usr/bin

Target binaries are an open issue. 

Theoretically into /usr/$target/bin, but this directory is being used by
binutils and GCC. IMO, this is a bug, because all other dirs
below /usr/$target contain target files, and AFAICT is occasionally
being worked at, but so far has not been resolved.

However, this isn't an actual issue because a cross GNU cross toolchain
does't contain any target binaries.

> For example /usr/bin/arm-unknown-linux-gnu-ld is maybe acceptable,
Right, this is the right place and the right name for a cross ld.

>  but
> that will also give a /usr/arm-unknown-linux-gnu/bin/ld,
Exactly, this is the troublesome spot I was referring to above. However
note: even these are host binaries.

>  and also
> a /usr/info/ld.info (collision with every other binutils package).
Yes, this is an other issue. Unlike the manpages, which are
canonicalized, the infos have not been canonicalized.

I am aware about some people having tried to resolve this, but AFAIK, so
far without success. I.e. the remedy is not to install a cross compilers
info files.

Similar issues exist wrt. i18n, the files conflict with a native cross
toolchain's i18n files (My work-around --disable-nls), and with some
languages' support files (esp. C++ headers - My work-around:
--enable-version-specific-runtime-libs, this folds the target
libs/headers etc. into gcc's internal directories).

And then is gnat/ada ;) ...
IMNSHO, forget about it wrt. cross compilers.

Installing to /opt, doesn't have all these issues.

Ralf