Re: Proposal: cross-compiling / development packaging guidelines

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


On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote:
> Hi All,
Comments interspersed ...

> Now that the setting of all this is clear on to the more interesting stuff
> how should cross-devel packages for Fedora look? Proposal:
> 1) binutils, gcc, glibc and other libraries for avr / arm-linux will use the
>     exact same upstream version as the native versions where-ever possible
> 2) All package names will be prefixed with the same prefix as binutils and
>     gcc use, examples:
>     avr-binutils, avr-gcc, arm-linux-binutils, arm-linux-gcc, arm-linux-glibc
Fine with me - It's the same approach am I am using for my cross-rpms.

> 3) The as,ld and gcc binaries:
>    * will be named avr-as, avr-ld and avr-gcc resp arm-linux-as, arm-linux-ld
>      arm-linux-gcc
>    * will be installed under /usr/bin
>    * will have links called as, ld and gcc installed under /usr/avr/bin resp
>      /usr/arm-linux/bin. More on these dirs below
This is the default with GCC.

> 4) libraries respectively headers will be installed under /usr/avr/lib resp
>    /usr/avr/include for avr and under /usr/arm-linux/lib resp
>    /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS
>    compliant, still I believe this is the right way,

The default for GCC is ${prefix}/$(target)/{lib|include}. 
This default is almost impossible to change.

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

> Problems:
> 7) With the arm-linux target some libraries may have target specific compile
>     options, for example the gp2x handheld uses a special version of SDL with
>     patches to support the gp2x input buttons and video.
>     Proposed solution:
>     a) install headers and libs for special platforms/targets under their own
>        dir, for gp2x that would be /usr/arm-linux-gp2x/{lib,include}
That's the standard GCC approach for cross-toolchains.

>     b) and then create binutils and gcc wrappers called special-prefix-binname,
>        for example arm-linux-gp2x-gcc, these wrappers add
>        /usr/arm-linux-gp2x/{lib,include} to the beginning of the lib /
>        /include search paths and add flags for the cpu-type and other
>        hardware specifics. These wrappers would be put in a package called
>        gp2x-devel, which besides containing these wrappers would also Requires:
>        all the necesarry bits, so that someone who wants todo gp2x development
>        can just do a "yum install gp2x-devel" and get started.
This is the classical standard GCC wrapper approach for non-multilib'ed cross-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.


fedora-extras-list mailing list

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux