Andy Green wrote:
Hans de Goede wrote:
Andy Green wrote:
Ralf Corsepius wrote:
On Wed, 2007-06-13 at 00:25 -0600, Brendan Conoboy wrote:
David Woodhouse wrote:
Do we _actually_ need to build parts of glibc? Could we not get away
with a fake DSO which just provides the few symbols libgcc uses?
[snip]
Will follow up on this part tomorrow. I disfavor faking it, as it
were.
Binutils at least should be relatively easy. Here's a patch against
binutils/F-7 which lets me:
make DIST_DEFINES='--define "binutils_target i686-linux-gnu"' ppc
Even for this we have build system questions... how best to build
it for
each target architecture we want?
Generally, I think Hans and the rest at
http://fedoraproject.org/wiki/SIGs/Embedded have the right idea
here. Prefixing the target name to the package is a good plan for
most crosses. More fully, I see 3 options:
1. One srpm to rule them all. This seems like a bad idea as it
doesn't scale.
Right, it doesn't. You'd end up with a monsterous spec cluttered with
cases and many (unused) patches, because different vendors apply
different patch sets.
Yet if you can put the clutter issue aside, this is definitely the Holy
Grail. The spec file is the single point at which the uncontrolled
variance of the raw tarballs are smoothed into a normalized Fedora
package.
Having multiple specs is going to lead to duplication of information and
loss of coherence when changes are made.
How about... a single Holy Spec, exactly what Fedora has right now, but
which gets dynamically pre-patched if there is stuff needed for cross on
a particular package that can't be hidden in the rpmmacros? The set of
arch spec patches lives in the SRPM like the other patches. This:
- keeps a single Fedora basic spec
- allows non-cross folks to totally ignore the existence of cross if
they like
- allows maintainability
- visibility of what is done for per-arch cross
One single spec might be an idea for Fedora-Fedora cross packages, but
it is not the answer for Fedora-Other (Embedded) OS target.
For example the gp2x sdk uses binutils 2.16.1 and glibc 2.3.5, so I
don't think stuffing this into the main Fedora binutils and glibc specs
is a good idea.
Maybe I didn't make my actual point clear in that (or maybe I don't get
your objection)... the idea is you maintain a patch against the existing
Fedora spec file for any package and arch that needs meddling with. So
there is one spec file same as right now - unchanged - but you have
additional per-arch pre-patches in the SRPM as well for cross cases that
need them. Non-cross people who don't go look at the patches aren't
even aware anything has changed let alone see things "stuffed" or
"cluttered".
You don't get my objectino, I'm crossing from Fedora but not too Fedora,
therefore what is in Fedora's specfile is completely irrelevant. Extreme
example, the sdcc cross-compiler already in Fedora. This crosses from Fedora to
8051 (and other) microcontrollers. It uses its own assembler and is its own
C-compiler, binutils and gcc are not used at all (except for building the asm /
compiler themselves, duh). Should the sdcc specfile be a pathc on top of gcc's
specfile, a patch effectively replacing 100% of it, just because its a
c-compiler too?
Also see my reaction to David Woodhouse last mail.
Regards,
Hans
-Andy
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
