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