On Wed, 2010-09-01 at 17:00 +0200, Gerd Hoffmann wrote:
On 09/01/10 16:46, Andrew Haley wrote:
>>> rpm2cpio package | cpio -i -
>> Isn't that easy, you'll have to do a bunch of fixups after doing so to
>> have things actually work.
> Usually not. Nine times out of ten, (probably 99 out of 100) all you
> need for cross-devel is the headers and the libraries, and they'll be
> in the right place after unpacking. The package doesn't have to work
> in that situation, it just has to be possible to build against it.
You havn't tried that, have you?
Last time I did I had to (a) move stuff from $sysroot/usr/... to
$sysroot/ to have compiler and linker find it. Also fixup paths in the
linker scripts (try 'cat /usr/lib64/libc.so'). Nothing really hard but
needs to be done.
>> Also automagic fetching of packages (including dependencies) would
>> be nice. Upgrading them even nicer.
> Lots of things sould be nice. It's not an argument for not providing
It isn't mean to be one.
>> Creating a script (or yum plugin?) doing all that is probably *much*
>> less work than creating tons of extra packages for userspace cross builds.
> Which we really shouldn't do. All this is irrelavant, and we're
> getting away from the core issue, which is about providing cross
If we go add cross-compilers it would be quite useful to also have an
easy ways to cross-build userspace stuff so we are not limited to kernel
cross builds ...
What are the use cases for the cross-compilers?
If these are to compliment the Fedora secondary archs, then compiling
kernels is probably the main use of cross-compilers -- for example, on
ARM, devices often need a custom kernel to go with a standard rootfs.
Once you're up on the device, you can build there, or you can use koji.
It's a principle of secondary archs that packages are built natively,
either on hardware or in emulation.
On the other hand, if you're trying to cross-compile userspace, that's a
whole different thing -- a lot more work, and perhaps much less needed.