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. > 2. One srpm which generates multiple crosses. This might be in the > form of one package for the Fedora mesh, another for all mips targets, > and so forth. The realm of when somebody wants to be a cross-arch-czar > or there is some technical reason to bunch them together. I am having doubts this can work, either, because different architectures/target OS aren't necessarily in a shape to be using the same sources. It definitely don't apply to embedded targets, which tend to require different versions on different architectures. > 3. One srpm which generates packages for a single cross, like Hans's > arm-gp2x-linux-package effort IMO, this is the only viable approach. It bloats the repos and requires some effort to assure packaging consistency when targeting several architectures/OSes, but it's basically what I am doing. > I favor a combination of #2 and #3. FWI: What I am doing for my cross-toolchain rpms is to generate the specs from a other, shared spec templates/fragments. > I'll see about adapting your > binutils patch to accommodate multiple targets, unless people think this > is a really bad idea. This idea probably can be made functional for targets addressing different archs of the same OS, but it doesn't work across OSes nor for embedded targets, because vendors often have different patches applied, even to binutils. Also, there occasionally are problems stemming from certain host/target combinations which render one of binutils/gcc/gdb components unbuildable for one host/target pair. A combined binutils is not unlikely to suffer from the same issues, which would mean "one broken" host/target pair is likely to block out all (E.g. I recently found binutils-2.17 for target sparc-rtems* to bomb out on x86_64, which they build flawlessly on i386). Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
