| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
The problem is that Libc is the place for exported interface changes from the xnu project to "meet the road." Libc is the rest of the world's window into xnu. In many instances, you must install the result of xnu's installhdrs pass in order to build the Libc that corresponds to it. If you don't have access to the needed version of xnu, you are out of luck trying to build Libc. Publishing new xnu versions to anoncvs is a very time consuming job for Apple. And so there we are...
I assume you mentioned somewhere in this thread why you need to go beyond the Libc version (Libc-207) that works with the xnu you already have. If it is to pick up some other feature inside Libc unrelated to xnu changes, I empathize. I've often thought of having a separate library (libmach.a) for the Mach interfaces to xnu, and then link it into libSystem.B.dylib (separately from libc.a). That way, the standard parts of libc can be picked up separately and indepedently. That would have solved your mig_strncpy() lock-step dependency problem, but it would not solve your SYS_sigwait problem (as Unix syscalls are defined to be in Libc). And besides, it would then require you to pick up a new cctools (dyld is dependent on Mach interface library changes), and that version of cctools would likely have already had some side-ways dependence on some of the new Libc changes, and you would be right back where you started. ;-(
| References: | |
| >Re: further divergences Libc vs xnu (From: Jim Magee <email@hidden>) |
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.