xcode4 - How can we restore ppc/ppc64 as well as full 10.4/10.5 SDK support to Xcode 4? - Stack Overflow

Tue Mar 22 11:27:54 PDT 2011

Note that Apple is gradually stopping support for ppc64.
Take for example the QTKit.framework, which is part of the quickTime player
and resides inside /System/Library. It is nowadays only "x86_64 i386
ppc7400".
Lots of graphic applications, and not only "video like" are linked against
the QTKit.framework.
So even if you get your XCode "patched" you still won't be able to compile a
lot of the graphic applications for ppc64.
A second dirty "patch" would then be to download the QuicktimePlayer 7.6.4
and extract the QTKit.framework from that one, as it is a full
4-architecture framework, to be able to build ppc64.
You can also imagine what other weird things might happen if you replace the
current QTKit.framework with that 7.6.4 QTKit.framework.

Just accept it: ppc64 is dead for Apple.

Harry

2011/3/22 Jeremy Huddleston <jeremyhu at macports.org>

> On Mar 22, 2011, at 06:34, Christopher Stone wrote:
>
> > Hey Folks,
> >
> > I haven't tried this but thought it worth passing along.
> >
> >
> http://stackoverflow.com/questions/5333490/how-can-we-restore-ppc-ppc64-as-well-as-full-10-4-10-5-sdk-support-to-xcode-4/5348547
>
>
> Two thinks there look particularly scary to me.  One is the assumption that
> the old gcc 4.0 xcplugin from XCode3 will "just work" with XCode4. The other
> is replacing the new assembler with the old one.  I'm not familiar with the
> xcplugin API to know if the first issue is something that we (MacPorts) can
> really do anything about, but I know that the second is.  The assembler (as)
> is part of the cctools package in XCode.
>
> XCode 3.2.6 has cctools-795
> http://opensource.apple.com/tarballs/cctools/cctools-795.tar.gz
> XCode 4.0.0 has cctools-800
> http://opensource.apple.com/tarballs/cctools/cctools-800.tar.gz
>
> The release notes* from 800 detail some changes between the two versions
> which you should probably be aware of if you decide to just replace it.
>  Many of these changes pertain to ARM support, so I would certainly not
> follow the advise on that website if you want to do iOS development.
>
> Of course for those interested in going down this road, it might be better
> just to build the newer as with ppc support in MacPorts.  I haven't tried
> this myself, but it should be fairly straightforward as it doesn't look like
> ppc support was removed at the source-level based on diffing the two
> projects and the list of changes in the release notes:
>
> Changes for the 5.29 release (the cctools-800 release):
> - Fixed the arm VCVT (between half-precision and single-precision)
> instructions
>  encodings.  Had the op bit inverted in the table.  It should have been:
>    VCVT<c><q>.F32.F16 <Qd>, <Dm> Encoded as op = 1 (aka fcvtshp)
>    VCVT<c><q>.F16.F32 <Dd>, <Qm> Encoded as op = 0 (aka fcvthps)
>  Radar bug #8951023.
> - Added the .incbin directive.  Radar bug #8945167.
> - Changed the Makefile to install the ppc and ppc64 assembler in LOCLIBDIR.
>  Radar bug #8828970.
>
> Changes for the 5.28 release (the cctools-799 release):
> - Found another path that -g was not checking to produce dwarf line table
>  entries only for the text section.  That was in dwarf2_emit_insn() in
>  dwarf2dbg.c.  Radar bug #8792738.
> - Fixed the mishanding of the thumb2 tst instruction.  Changed
> do_t_mvn_tst()
>  in arm.c.  Normally, the versions of the instructions that set condition
> flags
>  aren't allowed inside IT blocks, so it's checking that.  TST<c>, however,
> is
>  allowed and isn't accounted for.  Radar bug #8783763.
> - Changed the arm assembler for ADD/SUB (immediate, Thumb) to correctly
> follow
>  the manual's note about these instructions:
>    encoding T1 is to be preferred if Rd is specified, and T2 is preferred
> if
>    it is not.
>  To do this do_t_add_sub() sets the unused 0x0100 in inst.instruction when
>  using BFD_RELOC_ARM_THUMB_ADD to communicate to md_apply_fix() that two
>  operands were present in assembly code.  Then md_apply_fix() uses this bit
>  and checks the size of the immediate to see if the 3-bit immediate form
> can
>  be uses as it should be preferred in that case.  Radar bug #8756030.
>
> Changes for the 5.28 release (the cctools-798 release):
> - Changed to error messages in arm.c which were:
>    "invalid constant (%x) after fixup"
>  to have 0x in front of the hex value.  Radar bug #8772178.
> - Changed do_t_mul() in arm.c .  The problem is that the assembler didn't
> take
>  into account that the "mul" mnemonic (w/o the 's' suffix) is valid for the
>  16-bit wide encoding when in an IT block.  Radar bug #8755919.
> - Added support for make aarm_test .
>  - Added a arm-check.c that currently only does arm ALU instructions can
> set
>    the condition codes.
>  - Added #ifndef INSNS_TABLE_ONLY to arm.c so that can be #defined and
> included
>    in arm-check.c .
>  - Made the needed changes in the Makefile to add support for aarm_test .
>
> Changes for the 5.28 release (the cctools-797 release):
> - Changed the code that was adding the NULL DIE terminating the Compile
> Unit
>  DIE's when producing dwarf debuging info for assembly files to not be
>  conditional on if dwarf2_subprograms_info != NULL.  The change is at the
> end
>  of out_debug_info() in dwarf2dbg.c . Radar bug #8441990 and #8443177.
>
> Changes for the 5.28 release (the cctools-796 release):
> - Changed the x86-64 assembler to allow immediate expressions of the form:
>    movq $(xxx-L$y),%rax
>  by changing output_imm() to look for 4 byte signed 32-bit expression and
> use
>  the same trick in output_disp() to call fix_new() so it will use two
>  relocation entries pointing at the same 32-bits.  Radar bug #7081262.
> - Added the OpenSourceURL key to the cctools.plist file as:
>    <key>OpenSourceURL</key>
>    <string>
> http://ftp.gnu.org/gnu/binutils/binutils-1.38.1.tar.gz
> </string>
>  Radar bug #8569655.
>
> *: http://opensource.apple.com/source/cctools/cctools-800/as/notes
>
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110322/9eae662b/attachment.html>