On Thu, Jul 12, 2007 at 05:38:07PM +0300, Rabeeh Khoury wrote:
> I didn't get any feedback from the relevant maintainers, so
> decided to just go ahead and submit the ARM gcc and glibc package
> diffs to BZ:
Is gcj supported or still not?
It is not, due to some missing gcc bits, and making it work is not
just a matter of a 10-line patch (same thing holds for objective C,
but the rest of the languages work.)
It seems lots of Fedora advanced packages depends on this.
The only thing we can do in this case is to carry patches to disable
building the java parts of those packages (in case those packages
don't really depend on java but only e.g. ship java language bindings),
or just disable building the package entirely.
As to the first case, many packages fortunately already allow
building without their java bits (e.g. subversion.)
> It's still somewhat experimental (for example, I'm not
> satisfied yet about the sysroot handling), but it works well enough
> to cross-compile an ARM kernel, and it manages to cross-compile a
> native ARM gcc (i.e. build=i386 host=arm target=arm cross build) as
> well. Eventually, we'd like to be able to cross-build entire RPMS.
Can you please detail the big picture how this will work at the end?
For example building a package requires running natively some conftest.c
tests to discover availability of GPM (for example). Will it be needed
to patch every SRPM or there is emulation thing etc...
You have an ARM sysroot (basically, an ARM chroot) in
/usr/armv5tel-redhat-linux-gnueabi/sys-root (the default) or somesuch,
and when you cross-build packages for ARM, your cross-gcc (due to
having been build using --with-sysroot=yes itself) will look for
header files in /u/a/s/usr/include, ld will look for libraries in
/u/a/s/usr/lib, et cetera. This already works today, check out my
cross RPMS at:
To detect the availability of GPM devel libraries, you would typically
build a dummy application that includes gpm.h. If that works, gpm.h
is present on the system (in the sysroot) and building apps against it
will work, etc.
"Installing" an ARM package would then just be installing the package
into the sysroot. Things like post-install scripts make this 'interesting',
but there are several ways to deal with those: interpreting certain
commands such as ldconfig and useradd statically in the package manager
(which is what I think tsrpm does), or just running the postinstall
scripts using qemu-arm, et cetera.
In theory, if the app you are trying to build uses your $CC (i.e. does
not simply hardcode 'gcc' in its Makefiles) and doesn't do anything
stupid like trying to build a target executable and then trying to run
it, cross-building shouldn't need any changes. You of course still
have to make sure that the RPM spec file doesn't do anything similarly
stupid, but that's easy to fix.
Of course, there are enough apps that don't get this right (i.e. that
will not cross-build just by themselves), but you can just decide that
you'll fix the 100 most important packages and not bother with the
rest. I.e. you don't have to make _all_ of Fedora cross-buildable at
once to make this useful, you can easily do it incrementally.
I'll admit that I was pretty skeptical about the entire cross thing at
first (I always build everything except kernels natively on my ARM boxes
since they are fast enough), but having played with it a lot lately,
I'm a lot more convinced these days that it can actually work pretty