On Sun, 2006-09-17 at 22:41 -0400, Brendan Conoboy wrote:
> Any particular reason for the binutils in binutils_target? Something
> like target_triplet could be shared across multiple packages (gcc, gdb).
> Also, putting some form of Fedora in the name is great, but it should
> be in some way versioned like i686-fedora5-linux or even i686-fc5-linux.
> This is a little more specific and will scale better if cross compiler
> interest blossoms.
I only called it that to distinguish it from RPM's _target_cpu, which is
the _RPM_ target. And yes, something like i386-fedora6-linux would be
better.
> This seems like a pretty small divergence. Instead of target_triplet
> use target_triplets, use a for loop and you're scarcely any further from
> the original spec file. That said, three downsides come to mind:
>
> 1. The build will become increasingly slow as targets are added.
> 2. A build failure of one target may prevent any target RPMs from being
> produced (optional).
> 3. If people want to take the idea and run with it for other targets, a
> single SRPM means less flexible maintainership.
Perhaps we could build all the Fedora cross-toolchains in a loop like
that, but let people take it and do more esoteric targets individually
in Extras.
> The question that's been gnawing on my mind since your original posting
> is: Where does the sys-root come from? Clearly for the Fedora targets,
> there exist RPMs that contain the needed files from the existing build
> process. These need to be available when generating the crosses. Your
> binutils.spec (nice) assumes there is an installation under
> "/usr/%{binutils_target}". Whether or not this is the right place, it'd
> be good for there to be a dependency that ensures this exists.
Binutils doesn't need it. I can build kernels quite happily without.
> My current thought is that there be a wrapper spec file that takes in
> the target's RPMs, puts them in a standardized directory
> "/usr/share/sys-roots/%{target_triplet}" (imperfect location of the
> day), then makes a noarch RPM out of the contents. Is this possible in
> the build system? How do we accommodate the GPL here?
If it's our own packages then we're already shipping the source, so the
GPL shouldn't be an issue if we repackage them.
Note that we want all this for populating qemu sysroots already. And we
want to _share_ our sysroot with qemu. We might want ia32el using the
same system too.
I don't actually think we _do_ want to repackage them. If I want to be
able to install the proper i686 acrobat reader packages in to my i686
qemu/gcc sysroot, I want to just use yum -- or at _least_ RPM. I don't
want to have to repackage everything as noarch. We should be able to use
them directly, even if we have to modify rpm a little.
> Assuming this is a viable option, binutils (gcc, etc) could simply
> require this package prior to building. Having distinct sys-root
> packages also accommodates other (non-Fedora targeted) systems for
> which some interest has been shown.
I don't want to require it _prior_ to building. That might be OK for
Fedora where we _have_ the sysroot prior to building the compiler, but
when we don't have a pre-existing sysroot, we need to build the compiler
first.
See rants elsewhere over the last decade or so about dependencies and
building everything three times :)
> It would be great if Fedora could be cross compiled using any host
> system to produce binaries for any target system, be it a supported and
> rare host (s390, ia64) or an entirely new target (arm, mips*).
You'll never do that until we ban autoconf in packaging. Packages in
_general_ won't cross-compile. We'll always have to have a "native"
environment, although qemu can fake that and your _compiler_ binary can
be a real native binary in the middle of a target-sysroot, so it's nice
and fast. See scratchbox, for example.
--
dwmw2
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
