Bug 435546 - ExcludeArch ppc blocks ocaml-cil from building on ppc
ExcludeArch ppc blocks ocaml-cil from building on ppc
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: ocaml-cil (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
: FutureFeature, Patch
Depends On:
Blocks: F-ExcludeArch-ppc
  Show dependency treegraph
 
Reported: 2008-03-01 07:35 EST by Richard W.M. Jones
Modified: 2011-11-04 02:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ppc support patch (653 bytes, patch)
2008-03-01 13:32 EST, David Woodhouse
no flags Details | Diff

  None (edit)
Description Richard W.M. Jones 2008-03-01 07:35:12 EST
This package needs some love to make it build on ppc and ppc64.
Comment 1 David Woodhouse 2008-03-01 13:07:16 EST
Probably doesn't need much. I see comments like...

  *powerpc*darwin*)
    AC_MSG_RESULT(configuring for powerpc/darwin, which we treat like linux/x86)

Comment 2 David Woodhouse 2008-03-01 13:32:22 EST
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
we build?
Comment 3 Richard W.M. Jones 2008-03-01 13:44:23 EST
I used CIL to analyse libvirt.  There are some instructions about
what I did here:

http://et.redhat.com/~rjones/cil-analysis-of-libvirt/

At some point I'll be testing code with deputy
(http://deputy.cs.berkeley.edu/) again which makes lots of use
of CIL.

Anyway, thanks for the patch, I'll take a look later.
Comment 4 David Woodhouse 2008-03-02 11:34:03 EST
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.
Comment 5 David Woodhouse 2008-03-02 13:30:11 EST
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.
Comment 6 Bug Zapper 2008-05-14 01:42:58 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Richard W.M. Jones 2008-05-14 17:14:28 EDT
Back to Rawhide.
Comment 8 Gabriel Kerneis 2011-11-04 02:57:54 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.