On Wed, 2007-06-13 at 08:48 +0200, 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. The same was true of the kernel until we started slapping people and making them push their code upstream rather than dumping it in the RPM, and banning the use of %ifarch in the specfile (at least for applying patches). Having applied that discipline, this approach _does_ seem to work for the kernel. (So far, at least). I think Jakub does a good job of keeping patches to a minimum for the toolchain, just as we do for the kernel. Why should we expect less from those involved in cross-compilers? When I build an i386-fedora-linux-gnu cross-compiler package, I want that to be exactly the same compiler as the 'native' i386 compiler. The approach I've taken with binutils allows that. Perhaps we wouldn't get away with the same for gcc, but it would be nice if we could. > > 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. We really don't want to pander to this. If an architecture cannot work with a current toolchain, then we should just ignore it until the toolchain is fixed. They can get it working upstream, or they can sod off. Otherwise, they'll be asking us to ship their vendor-hacked 2.6.9 kernel next... and then we'll have to hurt them. > > 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. This would be a little nicer once we move to git and can just pull changes from Jakub's 'master' Fedora toolchain packages. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
