[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Proposal: cross-compiling / development packaging guidelines

On Thu, 2007-02-22 at 08:49 +0100, Hans de Goede wrote:
> Ralf Corsepius wrote:
> > On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote:
> <snip>
> > 
> > The default for GCC is ${prefix}/$(target)/{lib|include}. 
> > This default is almost impossible to change.
> > 
> I'm glad the things I "came up" with, closely match how you do things, thats 
> good to hear and for me a confirment that I'm on the right track.
> >> 5) Docs (manpages, info and docs under %doc) will not be installed as they
> >>     will be identical to the native version docs,
> > 
> > What you say only partially applies to gcc/binutils/gdb. Their section 3
> > man-pages are canonicalized (they install as <target>-manpage), hence
> > are free of conflicts with a native gcc. section-7 man-pages and infos
> > however conflict.
> > 
> Okay, so since the are installed as <target>-manpage, they won't conflict, but 
> will they contain any different content?
Yes - The contents depends on the version of tools being used.

As Fedora's binutils/GCC/gdb doesn't necessarily match the sources a
cross-toolchain uses, they can diverge.

>  I see no difference between "man 
> arm-linux-as" and "man as", since there is no difference is it worth installing 
This is a random coincidence wrt. the binutils, because the binutils
only change very slowly.

In case the versions drift apart, their contents also will differ. This
case is the "nominal case" for cross-toolchains, because different OSes
and different architectures normally require different toolchains.

> >> 8) The SRPMS for all these packages will most of the time contain the exact
> >>     same tarbals as the native binutils / gcc / libs
> >>
> >>     Possible solutions:
> >>     a) Live with the extra diskspace / bandwidth cost this induces upon
> >>        our mirrors
> > That's what I'd do.
> > 
> > An alternative would be to build different versions inside of the same
> > SRPMS at one time.
> > 
> That would require coordination between the cross-compile stuff maintainer and 
> the native maintainer, also that would force a rebuild of both native and cross 
> compile stuff if one of the 2 changes. I thought of this too but I don't see 
> this as a very realistic option.
I don't understand. The only point (besides infos) where a native
toolchain and cross-toolchains are tightly connected, is i18n/nls.
Getting i18n/nls working for cross-toolchains would require a
cross-toolchain to be using identical versions as the native toolchain,
or to tweak locale's paths.

For my cross-toolchain rpms I resorted to switching off i18n/nls.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]