Slashdot Mirror


Use x86 Boxes to Compile Mac OS X Binaries

IceFox writes "While working on the KDE on Darwin project I have only had one Mac to do development with. At the same time I have been playing around with distcc for Linux/x86 compiling. Combining the two projects I built a Mac OS X cross-compiler (for Linux/x86) and have created the DistccPPCKnoppix distribution. DistccPPCKnoppix is a 46MB Knoppix distribution based on distccKnoppix; with it you can use your extra x86 computers to build Linux/x86 or Mac OS X/PPC binaries. It might not be as shiny as an Xserve cluster, but it is a heck of a lot cheaper."

11 of 64 comments (clear)

  1. Re:This is news? by Ranger+Rick · · Score: 5, Informative

    The reason it's news is that GNU has no support for Mach-O, Apple has their own assembler and linker. Making them work on linux is a real pain in the ass.

    --

    WWJD? JWRTFM!!!

  2. Works in reverse, too...I think! by cbiagini · · Score: 4, Informative
    Well, I'd like to say that I think it's really cool that a Mac developer is so enthusiastic about his project that he's going this far to get the product out.

    But check out this excerpt from gcc's man pages:
    -arch arch
    Compile for the specified target architecture arch. The allowable
    values are i386 and ppc. Multiple options work, and direct the
    compiler to produce ``fat'' binaries including object code for each
    architecture specified with -arch. This option only works if
    assembler and libraries are available for each architecture speci-
    fied. (APPLE ONLY)
    Aww man...all my moderation's going to be undone in this discussion now. Well, to the person who said something funny up there: Good job.
    1. Re:Works in reverse, too...I think! by cremes · · Score: 5, Informative

      Specifying '-arch i386' on MacOS X doesn't work though. OSX doesn't ship with fat libraries, so it isn't possible to generate an x86 executable using the gcc switches. To make this work, you need to recompile several system frameworks and libraries and install them on your box. This is hairy. I saw instructions on how to do this about 2 years ago somewhere...

      Compiling ppc on x86 or x86 on ppc is actually a bit easier using OpenDarwin. You can run this fat on your hardware and emit fat executables just as the man page suggests.

      cr

  3. The iso download by IceFox · · Score: 4, Informative

    Hehe I learned my lesson before. I'll be putting the 46MB iso up later tonight, but if someone wants to host it you can e-mail me or im (aim: icefox2) me and I can get you the file.

    -Benjamin Meyer

    --
    Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
  4. Re:One more thing... by IceFox · · Score: 2, Informative

    Probably the same way that I do it under Linux. I alias make to make -j 32 in my bash init file and in the top of my path I have gcc g++ etc all point to distcc (just like the distcc man page gives as an example). So Xcode would just be calling make (really make -j 32) which calls g++-3.3 (really distcc). -Benjamin Meyer

    --
    Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
  5. Re:One more thing... by snowtigger · · Score: 4, Informative

    It's almost compatible already. XCode uses standard GNU gcc, g++, etc. for compiling.

    In XCode, the equivalent of a Makefile is called project.pbxproj (it's a text file) and the equivalent of make is a command called pbxbuild.

    So everything you need to do is to create the utility that parses project.pbxproj and compiles.

    Of course, make with a Makefile works perfectly fine, but XCode doesn't create those files for you.

  6. Re:Apple GCC vs. GNU GCC by tyrione · · Score: 2, Informative

    That changes with the very recent release of GCC 3.4 and moreso when GCC 3.5 is released.

  7. Re: One more thing... by aqsalter · · Score: 3, Informative

    And one more thing...

    PBTOMAKE -- Xcode .pbproj to Unix Makefile

    ??

    Why not, I hear you ask??

  8. Error in Title... by Big+Sean+O · · Score: 1, Informative

    The correct word is "Boxen" not "Boxes". Don't you know it's ironical to spell easy words wr0ng?

    And it's also the slashdot way to point out every teh and misused apostrophe.

    --
    My father is a blogger.
  9. Re:One more thing... by douthat · · Score: 3, Informative
    I beleive he was talking about making it compatible with XCode's built-in "distributed build", which works automatically via Rendevous and doesn't require any mucking around with command lines. (i.e. Just press the "Build" button)

    From Apple
    Distributed build Anyone could guess that bringing multiple processors to bear on a build would make it go much faster, but Xcode lets you act on the obvious solution. With the Rendezvous-enabled distributed build feature it's easy to simply farm out your build by distributing compile workload across idle desktop machines or, better, deploy a dedicated Xserve build farm to do in minutes what would take hours on any single machine.
    --
    She loves me: 09F911029D74E35BD84156C5635688C0 She loves me not: 09F911029D74E35BD84156C5635688BF ...
  10. Re:fruits by buckhead_buddy · · Score: 3, Informative

    Caveats: Xcode's distributed compiling is fantastic. It was an unexpected gift and I know a number of people who have networks to make great use of it. But...

    There is latency added to the compile process by having to distribute things out over the network. I think there was an Apple white paper or tech note that talked about these issues in more detail.

    It needs a speedy network. Apple engineers recommend Gigabit Ethernet but 100baseT will due in a pinch. They don't see much speed savings over 10BaseT or Airport.

    It needs fast processors. G5's are the recommended platform. Be wary of sub-Gigahertz G4's. Forget the G3's.

    The distributed compilation feature is a GREAT addition to XCode, but I still see a place for this project among those who are really on a tight budget (like me) but who still want to support Macs when feasible.