March 2008 - Darwin-dev - lists.apple.com

Re: Installing a kext on 10.5 (Leopard)
by Duane Murphy 15 Mar '08

15 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --- At Sat, 15 Mar 2008 15:10:38 -0700, Duane Murphy wrote: >I like the idea of using a different extension and then renaming after >the permissions changes. I take it back. If timeing is an issue here, this solution doesn't work. A full cache update would still be missed if the file is renamed and the folder touched during the cache update. A staging area would be best. One change; everything in the folder is always correct. I guess we may have to rely on /tmp. :-( ...Duane --- At Sat, 15 Mar 2008 15:10:38 -0700, Duane Murphy wrote: >Dean, >Thank you for the information. I think there are some things we can try >and do in here. > >Something that might not have been clear is that we are also counting on >the boot partition to be updated by kextd/kextcache. This has been the >significant issue. We have not seen this problem with installs that do >not have boot partitions. However, with boot partitions, we see this >problem intermittently. Maybe hanving the boot partition in the process >changes the cache update in ways that others are not seeing. > >I'll file a bug report, but reproducing this is a difficult. It just >feels like some kind of timing issue. > >>As long as the >>final touch happens within a few seconds after the mv, kextache will >>only be run once. > >This is, I think, where the timing issue comes in. > 1. The kext is copied into /S/L/E by the Package Installer > 2. Presumably, the cache rebuild starts as it notices the folder changed > 3. chmod, chown, touch the kext > 4. But the cache rebuild is still in progress so no update occurs > 5. Restart > 6. Can't reboot > >I've changes our script to make sure that kextcache runs after the >touch, but I believe kextcache is actually _still_ running from the >original copy and doesn't actually finish. > >I like the idea of using a different extension and then renaming after >the permissions changes. > >I've run into a process like this before, where an update is missed >because the data changes during the process. The solution I have used is >to keep updating until there are no changes. Updating just once, >especially for a lengthy process like rebuilding a file cache, can miss >a mid-update change. > >--- At Sat, 15 Mar 2008 10:59:17 -0700, Dean Reece wrote: > >>On Mar 15, 2008, at 10:35 AM, Duane Murphy wrote: >>> Hi Folks, >>> I'm installing a kext in /System/Library/Extensions. On Leopard we >>> are having trouble with the kext cache for a boot partition not >>> getting updated properly when the kext is installed. Of course this >>> results in the system becoming unbootable because the cache is out >>> of sync (at least that's what the output at boot time says). >>> >>> We are following the usual guidelines, but I get the idea that the >>> usual guidelines may not be appropriate for Leopard. >>> >>> The installer puts the kext folder into /System/Library/Extensions >>> then we do the chmod, chown dance to set privileges correctly, then >>> finally touch /S/L/E. >>> >>> I believe that on Leopard, kextcache is launched as a result of >>> using the new FSEvents mechanism. This in turn causes kextcache to >>> be kicked off when the folder is installed before the privilege >>> dance can be finished causing the cache to get out of sync. >> >>kextd is watching the extensions folder, so the final touch you do >>should (re)trigger the cache rebuild. >>If you are doing a touch after the kext install & perm dance, and the >>cache is not being rebuilt correctly, you need to file a radar. >> >>> It has been recommended to me previously to do the privilege dance >>> outside of /S/L/E and then move the kext into /S/L/E. The question >>> then becomes where is a good place to stage the kext? And is this >>> the right thing to do? >> >>Yes, it is the best thing to do on any version of OS X, since it >>guarantees you won't end up with a partially installed or updated kext >>if the system crashes at just the wrong time. >> >>On Leopard, kextd watches /S/L/E and it might rebuild more than once >>if the mod date of /S/L/E changes multiple times during your >>installation process. Using mv will make the kext installation >>atomic, so the kext can't be partially installed. As long as the >>final touch happens within a few seconds after the mv, kextache will >>only be run once. >> >>> The target directory should be on the same volume as /S/L/E and >>> support privileges (ie not have the "ignore privileges on this >>> volume" switch turned on). >>> >>> Is just using /S/L appropriate? >> >>You should not modify /S/L; that is only for Apple. In the future, we >>may provide a condoned staging area for this and/or a kext install >>script that you can just run from your installer, but for now, you >>need to find some other place to do this. >> >>> /tmp seems scary to me. Seems to easy (and to common) to remap to a >>> different volume for expert users. >> >>It is certainly possible, though the worst-case side effect of it >>being on a different volume is that the mv degrades to a cp. As long >>as you always followup with a touch of /S/L/E , then kextcache should >>rebuild with your complete kext (please file a radar if not). >> >>Alternatively, you can install your kext with a different extension, >>and rename it to foo.kext after you've completed the install/perm >>dance. Then, one final touch to /S/L/E and you should be good. >> >>> Seems like this change to kext loading could affect lots of >>> installations if I am correct. >> >>I am not aware of other reports of this, so if there is a bug in the >>cache rebuild logic, it isn't being widely seen or reported. >> >>> Thank you for your comments and recommendations. > > ...Duane ...Duane _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installing a kext on 10.5 (Leopard)
by Duane Murphy 15 Mar '08

15 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dean, Thank you for the information. I think there are some things we can try and do in here. Something that might not have been clear is that we are also counting on the boot partition to be updated by kextd/kextcache. This has been the significant issue. We have not seen this problem with installs that do not have boot partitions. However, with boot partitions, we see this problem intermittently. Maybe hanving the boot partition in the process changes the cache update in ways that others are not seeing. I'll file a bug report, but reproducing this is a difficult. It just feels like some kind of timing issue. >As long as the >final touch happens within a few seconds after the mv, kextache will >only be run once. This is, I think, where the timing issue comes in. 1. The kext is copied into /S/L/E by the Package Installer 2. Presumably, the cache rebuild starts as it notices the folder changed 3. chmod, chown, touch the kext 4. But the cache rebuild is still in progress so no update occurs 5. Restart 6. Can't reboot I've changes our script to make sure that kextcache runs after the touch, but I believe kextcache is actually _still_ running from the original copy and doesn't actually finish. I like the idea of using a different extension and then renaming after the permissions changes. I've run into a process like this before, where an update is missed because the data changes during the process. The solution I have used is to keep updating until there are no changes. Updating just once, especially for a lengthy process like rebuilding a file cache, can miss a mid-update change. --- At Sat, 15 Mar 2008 10:59:17 -0700, Dean Reece wrote: >On Mar 15, 2008, at 10:35 AM, Duane Murphy wrote: >> Hi Folks, >> I'm installing a kext in /System/Library/Extensions. On Leopard we >> are having trouble with the kext cache for a boot partition not >> getting updated properly when the kext is installed. Of course this >> results in the system becoming unbootable because the cache is out >> of sync (at least that's what the output at boot time says). >> >> We are following the usual guidelines, but I get the idea that the >> usual guidelines may not be appropriate for Leopard. >> >> The installer puts the kext folder into /System/Library/Extensions >> then we do the chmod, chown dance to set privileges correctly, then >> finally touch /S/L/E. >> >> I believe that on Leopard, kextcache is launched as a result of >> using the new FSEvents mechanism. This in turn causes kextcache to >> be kicked off when the folder is installed before the privilege >> dance can be finished causing the cache to get out of sync. > >kextd is watching the extensions folder, so the final touch you do >should (re)trigger the cache rebuild. >If you are doing a touch after the kext install & perm dance, and the >cache is not being rebuilt correctly, you need to file a radar. > >> It has been recommended to me previously to do the privilege dance >> outside of /S/L/E and then move the kext into /S/L/E. The question >> then becomes where is a good place to stage the kext? And is this >> the right thing to do? > >Yes, it is the best thing to do on any version of OS X, since it >guarantees you won't end up with a partially installed or updated kext >if the system crashes at just the wrong time. > >On Leopard, kextd watches /S/L/E and it might rebuild more than once >if the mod date of /S/L/E changes multiple times during your >installation process. Using mv will make the kext installation >atomic, so the kext can't be partially installed. As long as the >final touch happens within a few seconds after the mv, kextache will >only be run once. > >> The target directory should be on the same volume as /S/L/E and >> support privileges (ie not have the "ignore privileges on this >> volume" switch turned on). >> >> Is just using /S/L appropriate? > >You should not modify /S/L; that is only for Apple. In the future, we >may provide a condoned staging area for this and/or a kext install >script that you can just run from your installer, but for now, you >need to find some other place to do this. > >> /tmp seems scary to me. Seems to easy (and to common) to remap to a >> different volume for expert users. > >It is certainly possible, though the worst-case side effect of it >being on a different volume is that the mv degrades to a cp. As long >as you always followup with a touch of /S/L/E , then kextcache should >rebuild with your complete kext (please file a radar if not). > >Alternatively, you can install your kext with a different extension, >and rename it to foo.kext after you've completed the install/perm >dance. Then, one final touch to /S/L/E and you should be good. > >> Seems like this change to kext loading could affect lots of >> installations if I am correct. > >I am not aware of other reports of this, so if there is a bug in the >cache rebuild logic, it isn't being widely seen or reported. > >> Thank you for your comments and recommendations. ...Duane _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installing a kext on 10.5 (Leopard)
by Duane Murphy 15 Mar '08

15 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --- At Sat, 15 Mar 2008 20:18:54 +0100, Stephane Sudre wrote: >>> It has been recommended to me previously to do the privilege dance >>> outside of /S/L/E and then move the kext into /S/L/E. The question >>> then becomes where is a good place to stage the kext? And is this >>> the right thing to do? >> >> Yes, it is the best thing to do on any version of OS X, since it >> guarantees you won't end up with a partially installed or updated >> kext if the system crashes at just the wrong time. > >Is this also the procedure that should be followed when you install >your kext through a .pkg package? That would go against the idea >behind a .pkg. This is in fact how the kext is installed. Following the installation, the postflight script changes perms, etc and touches /S/L/E. ...Duane _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installing a kext on 10.5 (Leopard)
by Stephane Sudre 15 Mar '08

15 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 15, 2008, at 6:59 PM, Dean Reece wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Mar 15, 2008, at 10:35 AM, Duane Murphy wrote: Hi Folks, I'm installing a kext in /System/Library/Extensions. On Leopard we are having trouble with the kext cache for a boot partition not getting updated properly when the kext is installed. Of course this results in the system becoming unbootable because the cache is out of sync (at least that's what the output at boot time says). We are following the usual guidelines, but I get the idea that the usual guidelines may not be appropriate for Leopard. The installer puts the kext folder into /System/Library/Extensions then we do the chmod, chown dance to set privileges correctly, then finally touch /S/L/E. I believe that on Leopard, kextcache is launched as a result of using the new FSEvents mechanism. This in turn causes kextcache to be kicked off when the folder is installed before the privilege dance can be finished causing the cache to get out of sync. kextd is watching the extensions folder, so the final touch you do should (re)trigger the cache rebuild. If you are doing a touch after the kext install & perm dance, and the cache is not being rebuilt correctly, you need to file a radar. It has been recommended to me previously to do the privilege dance outside of /S/L/E and then move the kext into /S/L/E. The question then becomes where is a good place to stage the kext? And is this the right thing to do? Yes, it is the best thing to do on any version of OS X, since it guarantees you won't end up with a partially installed or updated kext if the system crashes at just the wrong time. Is this also the procedure that should be followed when you install your kext through a .pkg package? That would go against the idea behind a .pkg. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installing a kext on 10.5 (Leopard)
by Dean Reece 15 Mar '08

15 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Cheers, - Dean _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Mar 15, 2008, at 10:35 AM, Duane Murphy wrote: Hi Folks, I'm installing a kext in /System/Library/Extensions. On Leopard we are having trouble with the kext cache for a boot partition not getting updated properly when the kext is installed. Of course this results in the system becoming unbootable because the cache is out of sync (at least that's what the output at boot time says). We are following the usual guidelines, but I get the idea that the usual guidelines may not be appropriate for Leopard. The installer puts the kext folder into /System/Library/Extensions then we do the chmod, chown dance to set privileges correctly, then finally touch /S/L/E. I believe that on Leopard, kextcache is launched as a result of using the new FSEvents mechanism. This in turn causes kextcache to be kicked off when the folder is installed before the privilege dance can be finished causing the cache to get out of sync. kextd is watching the extensions folder, so the final touch you do should (re)trigger the cache rebuild. If you are doing a touch after the kext install & perm dance, and the cache is not being rebuilt correctly, you need to file a radar. It has been recommended to me previously to do the privilege dance outside of /S/L/E and then move the kext into /S/L/E. The question then becomes where is a good place to stage the kext? And is this the right thing to do? Yes, it is the best thing to do on any version of OS X, since it guarantees you won't end up with a partially installed or updated kext if the system crashes at just the wrong time. On Leopard, kextd watches /S/L/E and it might rebuild more than once if the mod date of /S/L/E changes multiple times during your installation process. Using mv will make the kext installation atomic, so the kext can't be partially installed. As long as the final touch happens within a few seconds after the mv, kextache will only be run once. The target directory should be on the same volume as /S/L/E and support privileges (ie not have the "ignore privileges on this volume" switch turned on). Is just using /S/L appropriate? You should not modify /S/L; that is only for Apple. In the future, we may provide a condoned staging area for this and/or a kext install script that you can just run from your installer, but for now, you need to find some other place to do this. /tmp seems scary to me. Seems to easy (and to common) to remap to a different volume for expert users. It is certainly possible, though the worst-case side effect of it being on a different volume is that the mv degrades to a cp. As long as you always followup with a touch of /S/L/E , then kextcache should rebuild with your complete kext (please file a radar if not). Alternatively, you can install your kext with a different extension, and rename it to foo.kext after you've completed the install/perm dance. Then, one final touch to /S/L/E and you should be good. Seems like this change to kext loading could affect lots of installations if I am correct. I am not aware of other reports of this, so if there is a bug in the cache rebuild logic, it isn't being widely seen or reported. Thank you for your comments and recommendations. This email sent to site_archiver(a)lists.apple.com

1 0

Installing a kext on 10.5 (Leopard)
by Duane Murphy 15 Mar '08

15 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Folks, I'm installing a kext in /System/Library/Extensions. On Leopard we are having trouble with the kext cache for a boot partition not getting updated properly when the kext is installed. Of course this results in the system becoming unbootable because the cache is out of sync (at least that's what the output at boot time says). We are following the usual guidelines, but I get the idea that the usual guidelines may not be appropriate for Leopard. The installer puts the kext folder into /System/Library/Extensions then we do the chmod, chown dance to set privileges correctly, then finally touch /S/L/E. I believe that on Leopard, kextcache is launched as a result of using the new FSEvents mechanism. This in turn causes kextcache to be kicked off when the folder is installed before the privilege dance can be finished causing the cache to get out of sync. It has been recommended to me previously to do the privilege dance outside of /S/L/E and then move the kext into /S/L/E. The question then becomes where is a good place to stage the kext? And is this the right thing to do? The target directory should be on the same volume as /S/L/E and support privileges (ie not have the "ignore privileges on this volume" switch turned on). Is just using /S/L appropriate? /tmp seems scary to me. Seems to easy (and to common) to remap to a different volume for expert users. Seems like this change to kext loading could affect lots of installations if I am correct. Thank you for your comments and recommendations. ...Duane _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Darwin & IPv6 firwall?
by Andre-John Mas 15 Mar '08

15 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, With each computer I am able to connect to the following IPv6 addresses: http://www.kame.net/ http://ipv6.google.com/ Thanks Andre _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I currently trying to test an IPv6 setup and some of the problems I am having suggest that MacOS X may be blocking incoming IPv6 requests. The setup involves two computers on the same network, behind a DSL router with NAT. PowerMac G4, connected to IPv6 network using Aiccu (sixxs.net) MacBook Pro, connected to IPv6 network using Miredo Both computers have a web server running and ssh access, yet neither is able to ssh or open a connection to the other, yet they are able to connect to themselves using the same IPv6 address. Is there something that I might be missing? I am going to continue to see if I can find anything document else where, but if someone already knows something I don't I would appreciate the insight. This email sent to site_archiver(a)lists.apple.com

1 0

Re: DYLD_INSERT_LIBRARIES and read()
by Terry Lambert 14 Mar '08

14 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Yet other methods are used elsewhere. -- Terry On Mar 13, 2008, at 8:45 PM, Luke Daley <ld(a)ldaley.com> wrote: On 14/03/2008, at 12:51 PM, Terry Lambert wrote: Thanks Stephen, I tried and no dice. I am compiling with … Do I need to add something to that? Thanks Terry. Thanks. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… You are running into the general case that low level system interfaces are generally not extremely well documented as far as their internals or design philosophy is concerned. We compile each system call stub or decorated symbol for a library routine once per decoration. Each gets its own .o file. Then all versions of the .o file get added to the library, resulting in a library containing all versions of the symbol. In addition, there are default aliases. These tend to refer to the legacy behaviour for the benefit if older programs, but in some cases will refer to the new behaviour (new interfaces, or routines called from new interfaces). For example, x and x$UNIX2003 would refer to the function x legacy linkage, and x which is UNIX conformant. How this actually works depends on the call implementation. As a specific example, for 'kill', it means there's a second hidden parameter in the contract between the bottom of libSystem and the top of the kernel, and it gets the value of 0 or 1 based on whether or not a kill sent to a process group will also be sent to the caller (required by UNIX) or not (required for binary compatibility wi legacy applications that do not expect to handle a signal they send to their own process group). The library itself doesn't expose this contract at all. As another example, the difference in the error codes "ENOTSUPP" and "EOPNOTSUP" are mandated by UNIX to distinguish socket-specific non- support from general non-support, so they are required to have distinct values. In legacy systems, translation of the new EOPNOTSUP value for old software which hard codes error checking, instead of handling all errors, is done in an assembly error return stub for the call. If you are just wrapping the libSystem routines, and plan to call our functions after doing whatever your interposition layer does, you generally only need to create corresponding stubs for all functions. If you are planning anything else, well, start by learning how to build libSystem from the published sources, and make your changes relative to that. Also, if you don't need to interpose everything... don't! The Malloc debug library is an example of only interposing the symbols you need to, and leaving everything else alone. Take that approach, if at all possible. I have written an implementation of read(int, void*, size_t) that I am trying to use via DYLD_INSERT_LIBRARIES. I have this working fine on 10.4, but not on 10.5. I have read http://lists.apple.com/archives/Darwin-dev/2007/Nov/ msg00061.html but am still not clear on what I need to do. A follow up to that post mentions including a header. I can't seem to find any detail on this header. Look at the function prototype declaration in <unistd.h> on 10.5. You have to do yours the same way. Macros are defined in <sys/cdefs.h>. gcc -dynamiclib -o mylib.dylib -fno-common -framework CoreFoundation -mmacosx-version-min=10.4 mysource.c Specifically, I think I need to provide all 3 symbols (_read, _read $UNIX2003 and _read$NOCANCEL$UNIX2003) for this to work. The thing that's killing you is you are using -mmacosx-version- min=10.4 When we compile Libc, we compile it three times in order to get the three versions of the symbols, once each with different definitions. You'll never get the $NOCANCEL version of the symb (the one that avoids the _thread_testcancel() at the start of the system call in the kernel) on a 10.4 deployment target. Just to clarify, I need to build three different dylibs? There is no way to produce one dylib with all three symbols? Apologies for what may be obvious questions. I am a bit out of my depth here. LD. This email sent to site_archiver(a)lists.apple.com

1 0

Re: DYLD_INSERT_LIBRARIES and read()
by Luke Daley 14 Mar '08

14 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 14/03/2008, at 12:51 PM, Terry Lambert wrote: Thanks Stephen, I tried and no dice. I am compiling with … Do I need to add something to that? Thanks Terry. Thanks. LD. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I have written an implementation of read(int, void*, size_t) that I am trying to use via DYLD_INSERT_LIBRARIES. I have this working fine on 10.4, but not on 10.5. I have read http://lists.apple.com/archives/Darwin-dev/2007/Nov/ msg00061.html but am still not clear on what I need to do. A follow up to that post mentions including a header. I can't seem to find any detail on this header. Look at the function prototype declaration in <unistd.h> on 10.5. You have to do yours the same way. Macros are defined in <sys/cdefs.h>. gcc -dynamiclib -o mylib.dylib -fno-common -framework CoreFoundation -mmacosx-version-min=10.4 mysource.c Specifically, I think I need to provide all 3 symbols (_read, _read $UNIX2003 and _read$NOCANCEL$UNIX2003) for this to work. The thing that's killing you is you are using -mmacosx-version- min=10.4 When we compile Libc, we compile it three times in order to get the three versions of the symbols, once each with different definitions. You'll never get the $NOCANCEL version of the symb (the one that avoids the _thread_testcancel() at the start of the system call in the kernel) on a 10.4 deployment target. Just to clarify, I need to build three different dylibs? There is no way to produce one dylib with all three symbols? Apologies for what may be obvious questions. I am a bit out of my depth here. This email sent to site_archiver(a)lists.apple.com

1 0

Re: DYLD_INSERT_LIBRARIES and read()
by Terry Lambert 14 Mar '08

14 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I have written an implementation of read(int, void*, size_t) that I am trying to use via DYLD_INSERT_LIBRARIES. I have this working fine on 10.4, but not on 10.5. Thanks Stephen, I tried and no dice. I am compiling with … Do I need to add something to that? The thing that's killing you is you are using -mmacosx-version-min=10.4 -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Mar 13, 2008, at 5:00 PM, Luke Daley wrote: On 13/03/2008, at 5:19 PM, stephen joseph butler wrote: I have read http://lists.apple.com/archives/Darwin-dev/2007/Nov/ msg00061.html but am still not clear on what I need to do. A follow up to that post mentions including a header. I can't seem to find any detail on this header. Look at the function prototype declaration in <unistd.h> on 10.5. You have to do yours the same way. Macros are defined in <sys/ cdefs.h>. gcc -dynamiclib -o mylib.dylib -fno-common -framework CoreFoundation -mmacosx-version-min=10.4 mysource.c Specifically, I think I need to provide all 3 symbols (_read, _read $UNIX2003 and _read$NOCANCEL$UNIX2003) for this to work. When we compile Libc, we compile it three times in order to get the three versions of the symbols, once each with different definitions. You'll never get the $NOCANCEL version of the symb (the one that avoids the _thread_testcancel() at the start of the system call in the kernel) on a 10.4 deployment target. This email sent to site_archiver(a)lists.apple.com

1 0