Red Hat Bugzilla – Bug 435546
ExcludeArch ppc blocks ocaml-cil from building on ppc
Last modified: 2011-11-04 02:57:54 EDT
This package needs some love to make it build on ppc and ppc64.
Probably doesn't need much. I see comments like...
AC_MSG_RESULT(configuring for powerpc/darwin, which we treat like linux/x86)
Created attachment 296457 [details]
ppc support patch
It really does look like this is all that's needed -- we don't make much use of
the arch information at all, and instead get everything from the underlying
compiler (including function descriptors, AFAICT, so ppc64 should be good too).
The CIL documentation says:
CIL is relatively independent on the underlying machine and compiler. When you
build it CIL will configure itself according to the underlying compiler.
However, CIL has only been tested on Intel x86 using the gcc compiler on Linux
and cygwin and using the MS Visual C compiler.
Do we have a test suite, or anyone familiar with the software to approve what
I used CIL to analyse libvirt. There are some instructions about
what I did here:
At some point I'll be testing code with deputy
(http://deputy.cs.berkeley.edu/) again which makes lots of use
Anyway, thanks for the patch, I'll take a look later.
It seems OK for ppc32, and passes its own tests although I haven't tested it
harder. The ppc64 build shows a compiler problem -- not a miscompilation but
just that we're overflowing the TOC. That's fixed by patch (to ocaml) at
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052442.html but I'm not sure
it's the best answer. It causes the linker to complain a lot, although I think
the complaints are bogus.
Hm. A simpler answer might be to stop cil from creating a 'libcil.a' which isn't
really an archive at all, but is just a normal object file. The PPC64 ABI
doesn't allow multiple TOCs in in object files. When building an executable or a
shared library, the linker can cope. It's just 'ld -r -o libfoo.o *.o' that breaks.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Back to Rawhide.
This should be fixed in the next upstream release (1.4.0), scheduled in a few days.
I did not test it, though, but libcil.a has been renamed to libcil.o (btw, I'm not sure your cil-1.3.7-output-obj.patch is still necessary, works fine for me without it) and the configure targets added accordingly.