On Thu, Jul 12, 2007 at 05:38:07PM +0300, Rabeeh Khoury wrote: > > I didn't get any feedback from the relevant maintainers, so I > > decided to just go ahead and submit the ARM gcc and glibc package > > diffs to BZ: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246800 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246801 > > 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 entirely > > 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: http://www.wantstofly.org/~buytenh/cross/ 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 well.
