I am trying to recompile Superhai's GenericCPUPM to Snow. For 32 bit it works but the message
QUOTE
Warning - kext com.superhai.driver.GenericCPUPowerManagement has immediate dependencies on both com.apple.kernel* and com.apple.kpi.* components; use only one style.
In 64 bit it is error.
If I exclude such dependencies then
QUOTE
bash-3.2# kextutil /System/Library/Extensions/GenericCPUPowerManagement.kext/Cache file /System/Library/Caches/com.apple.kext.caches/Directories//System/Library/Extensions/KextIdentifiers.plist.gz is out of date; not using.
(kernel) kxld[com.superhai.driver.GenericCPUPowerManagement]: The following symbols are unresolved for this kext:
(kernel) kxld[com.superhai.driver.GenericCPUPowerManagement]: __ZN5IOCPU9metaClassE
(kernel) Can't load kext com.superhai.driver.GenericCPUPowerManagement - link failed.
(kernel) Failed to load executable for kext com.superhai.driver.GenericCPUPowerManagement.
(kernel) Kext com.superhai.driver.GenericCPUPowerManagement failed to load (0xdc008016).
(kernel) Failed to load kext com.superhai.driver.GenericCPUPowerManagement (error 0xdc008016).
Failed to load GenericCPUPowerManagement.kext - (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).
bash-3.2#
Is there anybody knows what to do if a kext has kernel dependencies?
QUOTE (Slice @ Jan 29 2010, 11:53 AM)
Is there anybody knows what to do if a kext has kernel dependencies?
Yes, you add the dependencies to the Info.plist or remove the dependency from the source. Here you need to find an alternative to IOCPU::metaClass as only apple signed kext are allowed to use com.apple.kpi.private in which IOCPU::metaClass is. If I will guess it is because of the IOKit "rtti" OSDynamicCast that causes the problem.
The next question however is why are you compiling this old source?
QUOTE (Superhai the Great @ Jan 29 2010, 03:41 PM)
Yes, you add the dependencies to the Info.plist or remove the dependency from the source. Here you need to find an alternative to IOCPU::metaClass as only apple signed kext are allowed to use com.apple.kpi.private in which IOCPU::metaClass is. If I will guess it is because of the IOKit "rtti" OSDynamicCast that causes the problem.
The next question however is why are you compiling this old source?
With those sources I have working GenericCPUPMControl.app which is fine. You mean that VoodooPower is better? I have no full functional sources of it. Is it possible to rewrite VoodooPower for Snow64 and use the app with it?
I think I can replace a class IOCPU with my own class including full implementation. Or may be it is better exclude the class at all. I didn't decide yet.
QUOTE (Slice @ Jan 29 2010, 07:53 PM)
I am trying to recompile Superhai's GenericCPUPM to Snow. For 32 bit it works but the message
In 64 bit it is error.
If I exclude such dependencies then
Is there anybody knows what to do if a kext has kernel dependencies?
Hi Slice
I also tried to compile SMBIOSResolver from SuperHai's source, ang 32bit is working in Snow. But not in x64.
I think it has the same issue like this.
Can you help me.
Thanks
SMBIOSResolver.zip ( 18.36K )
Number of downloads: 24 This post has been edited by rals2007: Jun 1 2010, 06:36 AM
Yes I know it's none of my business...but why would you want to use SMBIOSResolver when you can use vanilla AppleSMBIOS.kext and set all that stuff in /Extra/smbios.plist.
QUOTE (Gringo Vermelho @ May 31 2010, 08:32 AM)
Yes I know it's none of my business...but why would you want to use SMBIOSResolver when you can use vanilla AppleSMBIOS.kext and set all that stuff in /Extra/smbios.plist.
Hi Gringo
Im using HP 110 Netbook, Have to use SMBIOSResolver to get rid of "Error getting reference to IODeviceTree:/Options".
Other thing is, Using UUID fix in smbios.plist or com.apple.boot.plist doesnt do anything. Still have to use PlatformUUID kext.
But using SMBIOSRResolver, it solved the 2 issues i mentioned above. I hope i explained it well
I know the 32Bit of SMBIOSResolver will do just fine on my Netbook, since its only32bit. But my point here is, i just would like to have a Universal kext of it.
Please help This post has been edited by rals2007: Jun 1 2010, 06:38 AM
I think you use bad bootloader.
Good one create /Options and correct UUID.
No future for SMBIOSresolver.
QUOTE (Slice @ Jun 4 2010, 05:13 AM)
I think you use bad bootloader.
Good one create /Options and correct UUID.
No future for SMBIOSresolver.
Hi Slice
I agree. But i think it would be an easier fix for me if i do it in SMBIOSResolver, rather than in chameleon.
Can you help me out by fixing the kernel dependencies in the source?
Thanks
This post has been edited by rals2007: Jun 5 2010, 08:45 AM
While waiting for someone to help, try Asere's variant of Chameleon 2.0 RC4:
http://www.efixusers.com/showthread.php?t=644If you're already running Chameleon 2.0 RC4 you can just drop in the boot file.
QUOTE (Gringo Vermelho @ Jun 6 2010, 05:33 AM)
While waiting for someone to help, try Asere's variant of Chameleon 2.0 RC4:
http://www.efixusers.com/showthread.php?t=644If you're already running Chameleon 2.0 RC4 you can just drop in the boot file.
I have tried it, but still having the same issue.
Thanks for the effort Gringo. I really appreciate it.
Kernel Dependencies For 64bit
Jan 29 2010, 10:53 AM
Quote
