New Clang branch for macosxbootloader

A couple of days ago I ask for Build instructions for macosxbootloader and today I added a new branch called clang so that people can start experimenting with my latest commits.

You can clone the repository by clicking on Clone in Desktop and follow the instructions. Make sure to select the clang branch or it will fail.

After that you simply enter

make [enter]

in a terminal window and hope for the best. Should compile fine (still 64-bit only).

Please note that this would not have been possible without the help of Andy due to my main SSD hardware failure. Thanks man! Also. My initial commit may not even work for you, on your Mac Pro. In fact I am pretty sure that it doesn’t, because only 64-bit compiles, but my time was up so… later folks!

29 thoughts on “New Clang branch for macosxbootloader

  1. Am a bit confused – in the piker-alpha/macosxbootloader GitHub tree there is nothing called “clang” or any makefile. In andyvand/macosxbootloader GitHub tree there is a Makefile but nothing named “clang”, so what exactly are you referring to when you say to make sure to select the “clang branch”??

      • Pike,

        OK I see what you mean — BUT, when I click on the clang branch and then click “Clone in Desktop” I get the master tree not the clang tree. So I clicked on the “Download ZIP” button and got the clang tree OK. Should the “Clone in Desktop” get whatever is the currently selected branch or always the master? The above was when the was running. I tried a command line “git clone” and that gives an error:

        $ git clone
        Cloning into ‘clang’…
        fatal: repository ‘’ not found

        so must be doing something wrong I guess. Any ideas?

        Also, I downloaded the stuff from AndyVand’s macosxbootloader github tree and got the boot.efi built but a couple of small problems. Will try your stuff and see if the same or different results and then let you know. Basically the installer package on his build results in a missing blessed file, as the “bless” command was not done, so his installer package results in the following:

        bash-3.2$ pwd
        bash-3.2$ ls -lai boot*
        852151 -rwxr-xr-x 1 root wheel 668920 Dec 18 04:13 boot.efi
        851575 -rwxr-xr-x 1 root wheel 668920 Feb 7 22:33 boot.efi.macpro1,1.32bit
        764237 -rw-r–r– 1 root wheel 583736 Feb 7 20:34 boot.efi.osx10p10p2.original.macbook
        bash-3.2$ bless –info
        finderinfo[0]: 143 => Blessed System Folder is /System/Library/CoreServices
        finderinfo[1]: 852023 => Blessed System File is
        finderinfo[2]: 0 => Open-folder linked list empty
        finderinfo[3]: 0 => No alternate OS blessed file/folder
        finderinfo[4]: 0 => Unused field unset
        finderinfo[5]: 143 => OS X blessed folder is /System/Library/CoreServices
        64-bit VSDB volume id: 0xA3B799A1F785E204

        So I manually “bless” and things are happy:

        bash-3.2$ sudo bless –folder /System/Library/CoreServices –file ./boot.efi
        bash-3.2$ bless –info
        finderinfo[0]: 143 => Blessed System Folder is /System/Library/CoreServices
        finderinfo[1]: 852151 => Blessed System File is /System/Library/CoreServices/boot.efi
        finderinfo[2]: 0 => Open-folder linked list empty
        finderinfo[3]: 0 => No alternate OS blessed file/folder
        finderinfo[4]: 0 => Unused field unset
        finderinfo[5]: 143 => OS X blessed folder is /System/Library/CoreServices
        64-bit VSDB volume id: 0xA3B799A1F785E204
        bash-3.2$ ls -lai | grep boot
        852151 -rwxr-xr-x 1 root wheel 668920 Dec 18 04:13 boot.efi
        851575 -rwxr-xr-x 1 root wheel 668920 Feb 7 22:33 boot.efi.macpro1,1.32bit
        764237 -rw-r–r– 1 root wheel 583736 Feb 7 20:34 boot.efi.osx10p10p2.original.macbook
        701799 drwxr-xr-x 3 root wheel 102 Dec 21 23:14

        If your’s does the same, then think that’s a bug, or is there no way to have the “bless” done as part of the package installer? Also think that the installer should copy the existing boot.efi file just in case there is a problem before removing it. I had manually made a copy of the existing boot.efi file, so I was OK, but others might not have done this.

        Anyway, it’s getting late here so will continue working on this tomorrow and let you know. Sorry for the long message – let me know if there is some other way to pass you this sort of detailed replay, rather than via a post here? Perhaps a private message or ???

        Also, the write-up I’m making is gonna be pretty details with images and other help, so how is best way to send to you when I’ve got something for you to look at? Is PDF OK or ??? Where/how to send to you?

        Thanks again for the help…


      • Clone in Desktop will pull both branches, and you can select a branch in the web interface and in the Github application. Click on “Branches” and select the “clang” branch or click on “master” at the left of it (Show branches). This will open a menu where you can select a branch.

  2. Well, I tried the boot.efi built from AndyVand’s stuff and it didn’t work – just hangs. Even tried to boot in single user (no graphics) and still hangs. So am building the boot.efi from your clang branch and will try that out tonight (macpro1,1 is not a the same place where I need to build). Will let you know more when i give it a try.

    I have two video boards in the MacPro1,1 system – a QuadroFX4500 and a 7300GT, both of which I don’t think are supported, but was hoping that at least a single user text only boot might work.

    Thanks again…

      • “make all” is what I did for Andy’s version (and what I did for your clang version as well, but have not been able to test it yet on MacPro1,1 system).

      • Mine is still 64-bit only, but you would normally compile a 32-bit version of boot.efi on Windows. Right?

        Edit: Sync your local tree and run “make” (just make) to compile a 32-bit only copy of boot.efi

      • OK will give that a try. But I did a diff on the results of “make all” and “make” and there is no difference whatsoever. The two boot.efi files are the same size but have a different “sum” result, but suspect that is some sort of time or date internal to the file, since running “make” or “make all” twice both produce different boot.efi files (same size but different sum’s). Does that make sense? So if there are no difference in the “make” or “make all” details (args to compiler and linker) can’t see there being any difference in the two boot.efi files, can you?

        Is there a way to tell if a boot.efi file is 64-bit or 32-bit just by looking at it?

        Anyway, I tested the boot.efi made yesterday from your clang branch with “make all” last night and still no luck. I don’t have windows – doing all this building on a MacBook running Yosemite 10.10.2 and then after the “make all” did a bless to move the new new boot.efi into place.

        The behavior of the MacPro1,1 system with only the disk with your clang “make all” boot.efi is a flashing folder with question mark (flashes off then on about once every 7 seconds). And all the time the disk access light is flashing on the drive (all other drives were unplugged).

        Another odd behavior was if I had other bootable disks on the MacPro and used the Option key held down to select which volume to boot from, the volume with the new boot.efi shows up in the list of bootable icons, but if I selected it, the system actually boots from a different volume. Suppose it’s because it didn’t find a “valid” bootable system on the volume I had selected.

        Also, would it matter if the partition with the test boot.efi is the 4th physical partition on the disk (first is EFI, next is another Yosemite 10.10.0 system, next is the Recovery for 10.10.0, then the Yosemite 10.10.2 with the special boot.efi, then an NTFS partition)?

        Anyway, will do a “make” (not a “make all”) and try that version of the boot.efi and see what happens. But doubt any different result because of there is no different switches to compiler or linker for “make” and “make all” (I did a “make clean” before each make so that everything got built fresh).

      • Hangs with a blank screen with Andy’s version (see my other comments below about your clang version before the latest changes you made). No Apple Logo or anything. Will see what happens with the new version you changed later tonight or early tomorrow (my time not yours). Am hoping the “verbose” change you made tonight will give more feedback if it does hang again and will let you know.

  3. I just downloaded the latest GitHub clang tree and built again – quite a bit of difference visually from yesterday.

    Personally I would like to see all the compiler switches used to compile and link everything, but must admit the output is easier to see what is happening during the build.

    And again the boot.efi from “make all” and from “make” is exact same size and two different runs of “make” or “make all” produce two boot.efi files that are the some physical size and have different sums (so again there must be some sort of date or time or both embedded in them) otherwise the result of running make twice I would expect to produce exactly the same file, so the sum’s would be the same.

    Will let you know tomorrow the results of latest built boot.efi versions.

    • The detailed output will eventually be available in a compiler log file, but that is not the case right now.

      Also. Make is just short for make all and make ARCH=i386 but I prefer the shortest commands possible. If it turns out that we need make ARCH=x86_64 then I will make that the default target.

  4. If you just do a “file boot.efi” it says if it’s 32 bit – and all the boot.efi files I built from your clang tree make file are all 32-bit:. Not sure what PE32+ or PE32 means, are you?

    $ file boot*
    –these first two files is the original one that Apple installs:
    boot.efi: PE32+ executable (EFI application) 32-bit
    boot.efi.macbook6,2.64bit.apple_original: PE32+ executable (EFI application) 32-bit

    –these are boot.efi files from your clang tree – first two from yesterday and next two from today
    boot.efi-clang-2-make: PE32+ executable (EFI application) Intel 80386 32-bit
    boot.efi-clang-2-make-all: PE32+ executable (EFI application) Intel 80386 32-bit

    boot.efi-clang-2-make-all_try-2: PE32 executable (EFI application) 32-bit
    boot.efi.macpro1,1.pike-clang.make_try-2: PE32 executable (EFI application) 32-bit

    — this is boot.efi from AndyVand GitHub tree build from a couple of days ago:
    boot.efi.macpro1.andyvand: Universal EFI binary with 2 architectures, x86_64, i386

    So that seems to be how to tell if the EFI file is 32 or 64 bit.

    • Ok. Interesting. I was so focussed in getting it to compile that I forgot to check the result. Good to see that you did not. Thanks for that.

      Also. It doesn’t matter what you use, because running: make, make all or make ARCH=i386 will all result in the same target. Only make ARCH=x86_64 is different, and that was why I asked what you used to compile when you used a Windows environment. Thing is. The original Apple and previous copies of boot.efi are all:
      PE32+ executable (EFI application) 32-bit. You figured that out already.

      Running: make, make all or ARCH=i386 results in:

      file bin/x86/Release/boot.efi results in: PE32 executable (EFI application) 80386 32-bit

      Running: make ARCH=x86_64 results in:

      file bin/x64/Release/boot.efi results in: PE32+ executable (EFI application) 32-bit

      We clearly want the same target, so let’s try again with make ARCH=x86_64 and let me know where that stops. Oh. I also enabled verbose mode, in Options.cpp, because that would tell us if it even starts up or not.

      Edit: Correction. We want PE32 executable (EFI application) Intel 80386 32-bit because 64-bit is not supported on the old 32-bit EFi models.

  5. The difference between two back-to-back “make” runs for the same boot.efi file is only 4 bytes difference:

    $ cmp –verbose boot.efi-clang-2-make-all boot.efi-clang-2-make-all_try-2
    137 56 351
    138 57 62
    217 371 264
    218 56 62

    Any idea what exactly this is?

    The first number is the byte number in decimal, the second and third numbers are the data in octal. So the first run of make produced 56,57 octal or 2e,2f hex, at bytes 137 & 138, and 371,56 octal or f9,2e hex at bytes 217 & 218 for the first run, and the second run produced 351 & 62 octal or e9 & 32 hex, and 264 & 62 octal or b4 & 32 hex.

  6. Found something and devised a fix…
    Look in clang-600.0.54/src/tools/clang/lib/CodeGen/BackendUtil.cpp
    You’ll notice the error that prevents compilation…
    The fix:
    #if 0
    if (DLDesc != TDesc) {
    unsigned DiagID = Diags.getCustomDiagID(
    DiagnosticsEngine::Error, “backend data layout ‘%0’ does not match ”
    “expected target description ‘%1′”);
    Diags.Report(DiagID) << DLDesc << TDesc;
    Enjoy… 😀

    • Yeah, the first thing I usually do is to search for the string. Easily found, but commenting out the error doesn’t seem like the right thing to do. I mean the backend is still borked.

  7. I built a version of the bootloader with the new tools.
    I had to modify cctools to fix conversion using mtoc and I had to change clang with the patch above…
    My github repo contains the necessary patches for building the bootloader properly now…
    You can check the result if you like, it’s pushed to my github repo including build results…
    Some other source mods were required to make this possible but now it works…
    I was also able to now use the assembly version of the Rijndael algorithms… should be a lot faster and smaller…
    So finally a nice update 😀

  8. Bob, I noticed the proper command you used for blessing the boot.efi file and have changed my postinstall script accordingly.
    Now the auto installer should properly install the boot.efi file and bless it accordingly.
    BTW – the commands for making the installers are:
    make newinstaller
    make legacy-installer
    These will create universal EFI files (2 architectures).

    • With an old Mac Pro you don’t want a fat file, because bigger files take longer to load/process. Remember. This due to the use of old hardware, with a much slower bus, and then every little bit of extra code will add time to the boot process.

    • I think that it is possible to port this feature to Clover, thanks to the macosxbootloader, and I don’t understand why it this isn’t already done, but I guess that the developers have other priorities/stuff to fix/port/implement.

  9. Pingback: Clang update for macosxbootloader | Pike's Universum

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s