Apple

Bingo! This is a big piece of the puzzle. The original info.plists were missing an OSBundleEntry for com.apple.iokit.IOPCIFamily. I’m now able to get it to manually load (but it’s staying persistently loaded over reboots, but that may have been due to my mucking around and will try on a clean OS).

I can’t thank you enough. I have been banging my head against this on and off for several days!

Jeremy

From: Brett George [mailto:email@hidden]
Sent: Monday, April 14, 2014 11:56 AM
To: Jeremy Kezer
Cc: email@hidden
Subject: Re: Kext loading errors after building with Xcode 5.1

Do you have the correct kext dependencies listed in your info.plist? You can run kextlibs to help with this.

Brett.

On Apr 9, 2014, at 8:20 PM, Phil Jordan <email@hidden> wrote:

Hi Jeremy,

On Thu, Apr 10, 2014 at 2:25 AM, Jeremy Kezer <email@hidden> wrote:

Unfortunately, the original author of the kext is no longer around, and I'm a bit of a neophyte with kexts. Also, our code isn't directly referencing the extended commands that are being complained about but is using the base configRead8 etc. But our non-extended calls are definitely the cause of these errors; if I comment our use of configRead8 the extendedConfigRead8 errors disappear.

configRead8 etc. are defined inline in the header and call down to the extended* versions directly, so it makes sense that those functions would be inlined in your kext as direct calls to the extended functions.

Why it's failing to link is less clear.

To try and see if this was an isolated problem to our kext, I added some calls to the AppleSamplePCI sample project (in such a way that they would not actually be executed but not stripped), and it worked fine. More head scratching ensued.

If I go back to Xcode 5.0.2, everything is fine.

I've had similar cases of spurious kext link errors in the past. They have always been down to linker arguments that were added manually or were inherited from an old Xcode version's project file. The fact that a fresh project doesn't have the problem leads me to think that might be the problem here too. I suggest comparing the linker and compiler command lines from the clean project with the one that's causing problems. I would expect there to be some discrepancy, and you can divide-and-conquer to track down the problem from there.

Hope that helps,

phil

--
http://philjordan.eu/ - Phil Jordan, software development contractor

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden