Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
Sign in to follow this  

Can't build IOGraphics-373.2 due to errors

2 posts in this topic

Recommended Posts

Topic title and description says it all. I need help to fix the 100 errors in order to build IOGraphics-330.


There are 67 errors in IOGraphicsFamily alone. Some of them conversion stuff (absolute time) but most of them seem to be caused by missing header (links) and/or frameworks. How do I fix this?


Any developers in here willing to help?





Share this post

Link to post
Share on other sites

Maybe This will help you


I found it here:


Figure that some other ppl may also encounter such compilation problems, I decide to share my experience here.
The last time I do the compilation was a couple years ago and not much can be remembered. So I downloaded the source code from apple's site and try to compile it again today.

My system is still in 10.6.3, so I downloaded the corresponding IOGraphicsFamily package. A initial compilation produced all kinds of errors and warnings including the one you mentioned. So I need to check each of them and fix it.

From my past experience, it is an fact that those header files are really missing in our system's framework folder where the compiler is trying to search. But these files actually have a copy in the IOGraphicsFamily project itself. To solve the problem, simply copy them to the system path. Open a terminal, cd to the project directory and do below things:
cd IOGraphicsFamily
sudo cp ./IOKit/graphics/*.h /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/graphics/
sudo cp ./IOKit/i2c/*.h /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/i2c/

Here, I not only copied the missing header files, also overwrote those already existing header files. I only find out that I need do this after I encounter a lot errors without a clue and finally it turns out that these existing header files are not updated to correct version by Mac OSX's system update at all.

That's all header files from the package itself. There is another missing header file, IOHibernatePrivate.h, which can not be found here. I googled and get it from apple's xnu source:
Here, xnu-1504.3.12 is the version for 10.6.3. You should check your version by typing "uname -a" in terminal.
So copy it to system path as well. Since I downloaded it to my Desktop, I type:
sudo cp ~/Desktop/IOHibernatePrivate.h /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/

All missing header file problems should be solved. Now check other errors.

A bunch of errors can be solved by editing IOKit/graphics/IOGraphicsPrivate.h:

1. comment out the line: extern "C" ppnum_t pmap_find_phys(pmap_t map, addr64_t va);

2. Add another include file: #include <kern/thread_call.h>

3. Add below declarations:
__OSAbsoluteTime(AbsoluteTime	abstime)
return (*(uint64_t *)&abstime);

#define AbsoluteTime_to_scalar(x)	(*(uint64_t *)(x))


#define AsUInt64(x)	 (x)


static inline const UInt64& AsUInt64(const AbsoluteTime& rhs)
return reinterpret_cast<const uint64_t&>(rhs);

static inline UInt64& AsUInt64(AbsoluteTime& rhs)
return reinterpret_cast<uint64_t&>(rhs);

static inline void absolutetime_to_nanoseconds(const AbsoluteTime& abs, UInt64* ns)
absolutetime_to_nanoseconds(AsUInt64(abs), ns);

static inline void nanoseconds_to_absolutetime(UInt64 ns, AbsoluteTime* abs)
nanoseconds_to_absolutetime(ns, reinterpret_cast<uint64_t*>(abs));

static inline void clock_get_uptime(AbsoluteTime* abs)

static inline void clock_interval_to_deadline(uint32_t interval, uint32_t scale_factor, AbsoluteTime* result)
clock_interval_to_deadline(interval, scale_factor, reinterpret_cast<uint64_t*>(result));

static inline void clock_interval_to_absolutetime_interval(uint32_t interval, uint32_t scale_factor, AbsoluteTime* result)
clock_interval_to_absolutetime_interval(interval, scale_factor, reinterpret_cast<uint64_t*>(result));

static inline void clock_delay_until(const AbsoluteTime& deadline)
static inline boolean_t	thread_call_enter1_delayed(thread_call_t call, thread_call_param_t param1, const AbsoluteTime& deadline)
return thread_call_enter1_delayed(call, param1, AsUInt64(deadline));

static inline void ADD_ABSOLUTETIME(AbsoluteTime* time, const AbsoluteTime* offset)
*reinterpret_cast<uint64_t*>(time) += *reinterpret_cast<const uint64_t*>(offset);

static inline void SUB_ABSOLUTETIME(AbsoluteTime* time, const AbsoluteTime* offset)
*reinterpret_cast<uint64_t*>(time) -= *reinterpret_cast<const uint64_t*>(offset);

static inline int64_t CMP_ABSOLUTETIME(const AbsoluteTime* lhs, const AbsoluteTime* rhs)
return (*reinterpret_cast<const uint64_t*>(lhs) - *reinterpret_cast<const uint64_t*>(rhs));


After editing, copy it again to the system path:
sudo cp ./IOKit/graphics/IOGraphicsPrivate.h /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/graphics/

There is still a problem related to "clock_delay_until". I can solve it the same way as shown in above code with the part that is commented out, but that will produce another error where the function clock_delay_until is referenced (it's confused when there are 2 overloaded versions of the function clock_delay_until). I did not figure out an elegant way to solve this. What I did is to edit IOFramebuffer.cpp, change the line:

Finally, there is an undefined function: vm_map_wire
I googled and find its declaration:
void vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end,
vm_prot_t access_type, boolean_t user_wire);
Since it's one of the low-level VM map API of the system, it should exist somewhere in the kernel already. So I simply add the declaration right before the function where vm_map_wire is used:
extern "C" {
void vm_map_wire(vm_map_t map, vm_offset_t start, vm_offset_t end,
vm_prot_t access_type, boolean_t user_wire);
After all these editing, the target "IOGraphicsFamily" compiled without errors, but still produced a lot of warnings. I checked them and don't think those are big problems.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Posts

    • SUCCESS!!! Finally all my THUNDERBOLT devices are hotpluggable!!   The solution is unbelievable, seems to work on all chipsets without using SSDT, and shifts the focus on the cause of all problems Thunderbolt: the cable THB_C!! Already in my previous post I noticed strange behavior by inserting the _DSM method in DSB2: PCIHotplugcapable Zero.
      Since then I've been trying to figure out how the XHC controller affected the Thunderbolt hotplug, until Crismac2013 suggested I disconnect the THB_C cable from the motherboard.
      Once disconnected, it was enough to add as an arbitrary inject my first Thunderbolt address (PXSX): <dict> <key>Comment</key> <string>PCI THUNDERBOLT 15d3 first entry</string> <key>CustomProperties</key> <array> <dict> <key>Disabled</key> <false/> <key>Key</key> <string>PCI-Thunderbolt</string> <key>Value</key> <integer>1</integer> </dict> <dict> <key>Disabled</key> <false/> <key>Key</key> <string>IOName</string> <key>Value</key> <string>pci-bridge</string> </dict> </array> <key>PciAddr</key> <string>01:00.00</string> </dict> and it works!! Now I have also added my last SSDT to get PCI information on System info.
      I suspect, however, that in this way the USB-C functionality will be lost, you should do a test!
      In any case this is a huge step forward and makes it obvious that we need to work on XHCs controller to solve the problems with the hotplug with THB_C cable connected.  
    • Normal, rotational hard drives doesn't have attributes for life... (not even all ssds have it).
    • right about logs.... but in my case unpatched apfs are boot slower
    • Test the configplist, copy the folder Other in place of yours, I have filtered the kext you need to your PC ... You should extract ACPI tables from the clover GUI with F4 and post it .... Before doing so, delete all the files you have in Clover Origin ...... We try to make this PC work like a real Macbookpro...... Post Photo DCPI manager Test.zip
    • I have this kinda issue with my monitor, it started a few months ago. Every now and then it will cut out completely, Audio still plays but my monitor like resets. Does it in Windows, macOS and linux. Benq gl2450ht I think my monitor is.

      Sent from my SM-G930F using Tapatalk