Jump to content

Different solutions


Andy Vandijck
 Share

925 posts in this topic

Recommended Posts

New version (V1.1)

Now supports OS X 10.4 and better and also has PowerPC and PowerPC 64 bit support inside the binary.

Legacy installer created and tested, it works fine now for all Macs ;)

Link to comment
Share on other sites

These are improved versions of the standard sources.

The linker (ld) works without crashing and should support many architectures.

The rebaser (rebase) can rebase a lot (even the dylinker, also known as dyld).

The other tools are also included and the whole lot is built under build/Release.

If you want to replace your ld files, put them here:

 

/usr/bin/ld

 

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld

 

You will then use the new version by default.

These are obviously built for Yosemite and are used for Xcode 6.1

Enjoy :D

EDIT: Added source diff, forgot to upload sorry ;)

EDIT2: I added the proper files.

Diff included... :)

ld64-241.9-AnV.diff.zip

ld64-241.9-AnV.zip

  • Like 2
Link to comment
Share on other sites

Please can you explain what it is?

It creates universal EFI binaries from 2 (or more) .efi files.

The output is identical to the boot.efi as used in Snow Leopard.

With this tool you can combine any EFI binary (PE or TE) into this type of binary.

This allows for example the creation of a new boot.efi file with multiple architectures.

Link to comment
Share on other sites

It creates universal EFI binaries from 2 (or more) .efi files.

The output is identical to the boot.efi as used in Snow Leopard.

With this tool you can combine any EFI binary (PE or TE) into this type of binary.

This allows for example the creation of a new boot.efi file with multiple architectures.

 

Thank you!

 

But for what exactly this kind boot.efi is useful? On which scenario? When it becomes useful? When I might need it at all? Thx!

Link to comment
Share on other sites

Thank you!

 

But for what exactly this kind boot.efi is useful? On which scenario? When it becomes useful? When I might need it at all? Thx!

For example when making a custom grub / elilo.

 

Or in case of OS X using a custom OS X booter like this one:

https://github.com/andyvand/macosxbootloader

 

This way the i386 and x86_64 architectures can be combined and used as one file.

Same way as Snow Leopard boot.efi

Example above has support for booting Yosemite (including using i386 (32-bit) EFI on an Apple).

It always can come in handy, it is a tool of 100KB with support for many architectures, now built for the 4 major OS X archs.

I tested it, it works fine in all cases...

Link to comment
Share on other sites

Thank you Andy!

 

It's still unclear for. Probably because I'm not involved into this development and still unfamiliar with entire context.

 

Do I understand correctly that it's useful only with macosxbootloader, not with Clover, etc?

Link to comment
Share on other sites

Explaining roughly, you can create

boot.efi one that supports the i386 architecture (32bit)

this way you get INSTALLING Yosemite in 32 bits, currently

from Mountain Lion OSX only supports 64bit x86_64.

I think that's it.

Congratulations Andy.

  • Like 2
Link to comment
Share on other sites

Thank you Mirone. 

 

Seems that developers are often poor on clear communication with audience. They are so involved, so deep inside, that they aren't able to spell it out with one single sentence, which any dumb understands :) It's not an insult against Andy. Just showing back. Thats all :) Anyway, my respect to you Andy, well done!

  • Like 1
Link to comment
Share on other sites

Thank you Andy!

 

It's still unclear for. Probably because I'm not involved into this development and still unfamiliar with entire context.

 

Do I understand correctly that it's useful only with macosxbootloader, not with Clover, etc?

It works with any PE/TE file and Clover could be one of the examples (for the drivers e.g.) so that it only needs one directory instead of a number of driver directories.

Clover has support for universal EFI.

Link to comment
Share on other sites

It works with any PE/TE file and Clover could be one of the examples (for the drivers e.g.) so that it only needs one directory instead of a number of driver directories.

Clover has support for universal EFI.

 

Sounds cool now. Any Wiki available? ;) 

Link to comment
Share on other sites

Sounds cool now. Any Wiki available? ;)

Not unless you count the github source page's wiki entry ;)

Link to comment
Share on other sites

@Andy, thank you! It is encouraging to know that at least everything necessary for the build is available from the Apple open source site.

 

After you pointed me at libbless, I got it from there. ;)

 

But if you don't mind, I'd appreciate a bit more "cooked"  info. For example, to complete the build, you probably had to add all the necessary frameworks and libraries to the project. Maybe you could post your project.pbxproj file? And/or help me remove my confusion and understand why the project.pbxproj file included in your kext_tools-326.90.2-AnV_R2 does not seem to contain all these references (or at least those references do not show in my Xcode)?

 

Also, I tried to google for Private OSXSDK, and got nothing useful - so obviously I'm not looking at the right place. Could you please point me at its location?

 

Thank you!

 

P.S. If it isn't too big a time-sink (and I understand you're probably busy enough), perhaps you could post a list of those extra things needed for kext_tools build?

Link to comment
Share on other sites

@Andy, thank you! It is encouraging to know that at least everything necessary for the build is available from the Apple open source site.

 

After you pointed me at libbless, I got it from there. ;)

 

But if you don't mind, I'd appreciate a bit more "cooked"  info. For example, to complete the build, you probably had to add all the necessary frameworks and libraries to the project. Maybe you could post your project.pbxproj file? And/or help me remove my confusion and understand why the project.pbxproj file included in your kext_tools-326.90.2-AnV_R2 does not seem to contain all these references (or at least those references do not show in my Xcode)?

 

Also, I tried to google for Private OSXSDK, and got nothing useful - so obviously I'm not looking at the right place. Could you please point me at its location?

 

Thank you!

 

P.S. If it isn't too big a time-sink (and I understand you're probably busy enough), perhaps you could post a list of those extra things needed for kext_tools build?

From the README file:

OSXPrivateSDK
=============

SDK target for opensource.apple.com code

1. Quit Xcode
2. `$ git clone git@github.com:samdmarshall/OSXPrivateSDK.git PrivateSDK`
3. `$ cd PrivateSDK`
4. `$ git submodule update --init --recursive`
5. `$ cd SDKBuilder`
2. `$ python SDKBuilder.py --sdk /full/path/to/PrivateSDK/PrivateSDK/`
3. Open Xcode and select "Private (10.9)" as your SDK Target


This is based on many of the projects on opensource.apple.com to build in a proper environment. 
Looking for contributions and fixes to add more compatibility to existing projects.

And you have it.

Similar for 10.10...

Just change the path to the downloaded private SDK...

Just use google for every missing header (look for .h errors) and copy them into your target SDK.

There are too many libraries needed to list them all (I don't even remember them all but they are on http://opensource.apple.com)

Takes a bit of work and a lot of headers but then it builds fine...

Some libraries are required such as libbless but there are others, use google, copy built results to SDK and resume build each time.

  • Like 1
Link to comment
Share on other sites

I have been successful up to step 7.

 

I assume step 6 meant in my case:

$ sudo python SDKBuilder.py --sdk /Users/uri/src/PrivateSDK/PrivateSDK10.9/

Because otherwise when I didn't specify 10.9 subdir it could not find SDKSettings.plist, and when I invoked it as non-privileged user it failed with 

OSError: [Errno 13] Permission denied: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/PrivateMacOSX10.9.sdk'

 

But once PrivateMacOSX10.9.sdk has been created in that root-owned directory (after I invoked python as root), I'm confused how to proceed - what to point Xcode at.

 

And my apologies for my significant ignorance of Apple/OSX/Xcode intrinsics (which I'm trying to remedy, but the progress is slow, and the learning curve appears steep). I swear that I'm better when it is straight Unix/Linux and make. :)

 


It looks like in the project I was trying to build (AppleRAID in this case, needed for lib bless, which in turn is needed for kext_tools) I needed to replace Base SDK with this Private SDK (10.9). Once I've done that, I got a Missing file error on

#include <MediaKit/MKMedia.h>

/System/Library/PrivateFrameworks/MediaKit.framework on my system does not include any headers :-(

 

Again, I used to think my Google-fu was adequate, but I can't find a pointer to those headers. :-(

Link to comment
Share on other sites

I have been successful up to step 7.

 

I assume step 6 meant in my case:

$ sudo python SDKBuilder.py --sdk /Users/uri/src/PrivateSDK/PrivateSDK10.9/
Because otherwise when I didn't specify 10.9 subdir it could not find SDKSettings.plist, and when I invoked it as non-privileged user it failed with

OSError: [Errno 13] Permission denied: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/PrivateMacOSX10.9.sdk'

But once PrivateMacOSX10.9.sdk has been created in that root-owned directory (after I invoked python as root), I'm confused how to proceed - what to point Xcode at.

 

And my apologies for my significant ignorance of Apple/OSX/Xcode intrinsics (which I'm trying to remedy, but the progress is slow, and the learning curve appears steep). I swear that I'm better when it is straight Unix/Linux and make. :)

 

 

It looks like in the project I was trying to build (AppleRAID in this case, needed for lib bless, which in turn is needed for kext_tools) I needed to replace Base SDK with this Private SDK (10.9). Once I've done that, I got a Missing file error on

#include <MediaKit/MKMedia.h>
/System/Library/PrivateFrameworks/MediaKit.framework on my system does not include any headers :-(

 

Again, I used to think my Google-fu was adequate, but I can't find a pointer to those headers. :-(

If you can't fix up something then (like in case of this mediakit part) you have 2 options:

Some things aren't absolutely required thus remove references as they aren't used on a hackintosh.

Other option:

Reverse engineer or in case of ObjC use a tool like class-dump to get the headers directly.

MediaKit.framework ;) (hence the MK prefix...)

It is private but ObjC RTTI has no secrets...

Look for class-dump sources and learn :D

I got many private headers including app store (CommerceKit.framework) that way ;)

  • Like 1
Link to comment
Share on other sites

Thank you!

 

Regarding option 1 (removing references) - I'd rather avoid it, because I'm trying to replace the full-functioning component of a "native" Mavericks (10.9.5) installation. So I'm concerned of unwittingly crippling it.

 

I got class-dump-3.5 build (so Xcode actually can do something useful :)), though to my surprise it did not even try to install the executables despite me configuring Build rules to do exactly that. Oh well, another small problem to solve. :-)

 

I copied class-dump manually to where it belongs, and will start attacking MediaKit.framework.

 

Probably I'll cry for help here many more times yet before it all runs. ;)

  • Like 1
Link to comment
Share on other sites

This is a simple tool I wrote to compare 2 binary files and show the differences between them.

The reason I wrote this was because of the need to create auto patches for Clover using stock and patched kexts.

I thus needed a way to get the differences...

Enjoy :D;)

Source is included, as usual...

hexdiff.zip

  • Like 3
Link to comment
Share on other sites

While I'm struggling, maybe you could clarify this point:

Just use google for every missing header (look for .h errors) and copy them into your target SDK

Say, using class-dump I get those .h files that Apple thoughtfully omitted from MediaKit.framework. What's the best way to add them to the build?

 

Also, how do I add more frameworks, libraries, and include files to this PrivateOSXSDK? Re-create it every time with the python script included? Or...?

 

Thanks!

Link to comment
Share on other sites

While I'm struggling, maybe you could clarify this point:

Say, using class-dump I get those .h files that Apple thoughtfully omitted from MediaKit.framework. What's the best way to add them to the build?

 

Also, how do I add more frameworks, libraries, and include files to this PrivateOSXSDK? Re-create it every time with the python script included? Or...?

 

Thanks!

If the MediaKit.framework is not present, copy it from /System/Library/Frameworks or /System/Library/PrivateFrameworks.

Add underneath the required folder Headers and copy the headers you created in there.

Make sure that if it is a Private framework that you add it to the framework search paths before you build ;)

Link to comment
Share on other sites

Just noticed: uploaded wrong files...

Same as cctools-862...

Will reupload proper ld64 and source diff as soon as I get home ;)

Sorry about this, just seem lately a bit preoccupied... (and making some mistakes in the process).

Link to comment
Share on other sites

My main Github page is here:

https://github.com/andyvand

 

At current it has the following projects:

- decompkernelcache: This is my decompkernelcache project, now also with updated code for LZVN decompression and soon it will be able to compress kernel cache too.

- Enoch: This is a custom build of ErmaC's Enoch bootloader, prebuilt with Xcode 6.1.1

- LZVN: Pike R. Alpha's LZVN tool with some enhancements, this can compress and decompress LZVN code and has C library for LZVN compression and decompression (except for lzvn_encode_partial which at the moment is still assembly).

- macosxbootloader: Custom version of boot.efi for Yosemite (and older) with universal EFI support. For booting Yosemite on 32-bit EFI Macs, such as the MacPro1,1 and 64-bit support too, this is in general a custom OS X boot.efi, also now support for building with Clover tools (GCC+binutils+latest nasm) or Xcode (needs mtoc and latest nasm), now also option for building installer packages and hackintosh specific version.

- UEFIRomExtract: My UEFI VBIOS .efi file extractor, includes windows version and sources ofcourse for both *nix and Windows versions.

 

Will update this page if more projects get added ;)

Enjoy :D

  • Like 12
Link to comment
Share on other sites

Added Github page for decompkernelcache.

Now has also updated lzvndec.c file by Pike R. Alpha and new lzvn.h (includes compression code).

Only thing needed is conversion from lzvnenc.s from LZVN project to C and needs to be adapted for compression of kernel cache.

Then LZVN project is fully finished...

See first post for Github link (includes updated decompkernelcache 1.8, 1.9 will follow with compression support soon).

Link to comment
Share on other sites

Added update for macosxbootloader.

Optimized code and implemented hackintosh build support.

It now should work on hackintoshes with a custom build too...

Link to comment
Share on other sites

 Share

×
×
  • Create New...