October 2004 - Darwin-dev - lists.apple.com

Compiling cctools with CodeWarrior/PEF
by Josh 15 Oct '04

15 Oct '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=nkFexOzxDh56kMPHzr4gMjYYn522W6gYp1NOBqs+oeP7hAu7lCgHmtkCEV+k3AkwMKkaTRG09ZfAe7lLc6PiJaCzkgwaH+KAGq9MnQIQopI/UCFWnV1k+eVpb9DKiCdnxHT3LJD9qIudLmXLb1ZpgP+fjy+Qi6If0Rb8KN+LTBU I'm trying to compile the some of the prebinding libraries included in cctools using Codewarrior. Ultimately, I want to call unprebind() from a Carbon CFM app. The problem is that it compiles as a Mach-O static library (and I need it to be static) and I can't call that from a CFM app. The other option is to compile it as a Carbon PEF library, but I can't get codewarrior to do this (mwpefcc gives me all sorts of errors with the #include statements). Anyone have any experience or tips with this? _______________________________________________ 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

Possible bugs in PowerMac7_2_PlatformPlugin
by Benjamin Herrenschmidt 15 Oct '04

15 Oct '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Hi ! While going through the platform plugin mecanism, more specifically, the thermal management for the various machine types, I noticed a couple of things that may be bugs (Darwin 7.5 base) So there are 4 configs. But what the datas in the XML show seem to be different to what the device-tree & probeConfig() seem to show. Here is what can be deduced from the XML: 0 is obviously uniproc, then we have 3 configs for dual CPU machines. 1 and 3 uses the "old style" fan control (one instance of PowerMac7_2_CPUFanCtrlLoop for each CPU, only 2 fans driven by each of them). The difference between them seem to related to the PID factors and min fan values for the U3/backside loop, possibly a U3 vs. U3H distinction (1 beeing U3 and 3 beeing U3H) While 2 uses the "new style" fan control PowerMac7_3_CPUCoolingCtrlLoop with 6 controls, that is 2 fans per CPU plus what seem to be the 2 pumps according to the device-tree of a Dual 2.5Ghz. That is ok so far. So it seem from the above that 0 is uniproc, 1 and 3 are "old style" (no cpu liquid cooling, that is no pumps control) machines while 2 has the CPU cooling pumps (the 2 additional controls mapping FCU fan rpm0 & 1). so now, if we look at probeConfig(), what do we see: - In the case where something is missing from the device-tree, this is especially true for the case of the "old" duals (first rev) where we don't have any child under /u3/i2c/fan, we "return(2)". Shouldn't this be "return(1)" ? this is lines 171 and 185. - Once we have everybody, we check if we have one of the fans called "rpm1" at reg value 0x12. This is typically one of the pumps. If so we return 2. That seem to be logical if 2 is really the water cooled system (ACS ?). _HOWEVER_ I do have a device-tree dump here of a PowerMac7_2 machines dual 2Ghz with U3 (I don't know if it's heavy) which _does_ have this property too (though the location string is "CPU A" and not "CPU A PUMP" and so it's probably not useable). So that means this machine would incorrectly be detected as config 2 while it should apparently be config 1. It has U3 rev 0x34 which is different from 0x35 found in a dual 2.5Ghz though, so this could be used for differenciating them. - Finally, we return 3 or 1 depending on IS_U3_HEAVY() which looks correct. So the above seem to show that at least my old dual 2Ghz is incorrectly identified, and maybe some others. Unless I've missed something of course... I've verified that with IORegistryExplorer, and indeed, the class that was instanciated is PowerMac7_3CPUCoolingCtrlLoop... Now of course, there may be a good reason for these ... Another thing I've noticed is that the device-tree of a dual2.5Ghz, for the PUMPs, shows rpm0 beeing "CPU B PUMP" on control-id 0x4000 (16384) and rpm1 beeing "CPU A PUMP" on control-id 0x4100 (16640), which seem to be the exact opposite as the definitions in the XML where CPUA_ACS is defined to be 0x4000 and CPUB_ACS 0x4100. I don't which of the XML or the device-tree is wrong here, but it's harmless as the pumps are currently both programmed to the same value, though it has almost been a bug in the linux driver I'm working on :) Regards, Ben. _______________________________________________ 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: linking shared libraries with dependent shared libraries
by Paul Forgey 13 Oct '04

13 Oct '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On Oct 12, 2004, at 7:58 PM, Peter O'Gorman wrote: Peter -- Peter O'Gorman - http://www.pogma.com _______________________________________________ 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… Yuck, but that worked. In a lot of ways I guess this has advantages because it allows the executables to be more resistant to library path environment attacks. But still, it really complicates the build process relative to the other platforms. The dynamic linker (dyld) will not find libraries like this if they are not in one of the default search paths (/lib /usr/lib /usr/local/lib $HOME/lib). I think you need to use install_name_tool(1). I suggest that you use the -headerpad_max_install_names flag and set the install_name of the libraries to /path/to/build/loc/libname.dylib. Then the libraries can find each other at build time. At install time, you can use the install_name_tool to change the libraries names. If the libs are going to be installed relative to the executable, you should make the install_name @executable_path/rel/path/to/libname.dylib. This email sent to site_archiver(a)lists.apple.com

1 0

Re: linking shared libraries with dependent shared libraries
by Peter O'Gorman 13 Oct '04

13 Oct '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) Paul Forgey wrote: Peter -- Peter O'Gorman - http://www.pogma.com _______________________________________________ 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'm aware of that option. I may as well explicitly link against the entire dependency tree, which is what I want to avoid. I'm setting install_name to the bare filename (no path) since the product can be re-rooted. The dynamic linker (dyld) will not find libraries like this if they are not in one of the default search paths (/lib /usr/lib /usr/local/lib $HOME/lib). I think you need to use install_name_tool(1). I suggest that you use the -headerpad_max_install_names flag and set the install_name of the libraries to /path/to/build/loc/libname.dylib. Then the libraries can find each other at build time. At install time, you can use the install_name_tool to change the libraries names. If the libs are going to be installed relative to the executable, you should make the install_name @executable_path/rel/path/to/libname.dylib. This email sent to site_archiver(a)lists.apple.com

1 0

Re: linking shared libraries with dependent shared libraries
by Paul Forgey 13 Oct '04

13 Oct '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On Oct 12, 2004, at 7:36 PM, Peter O'Gorman wrote: How about telling you to read the manpage for ld(1)? :-p Hope this helps, Peter _______________________________________________ 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'm aware of that option. I may as well explicitly link against the entire dependency tree, which is what I want to avoid. I'm setting install_name to the bare filename (no path) since the product can be re-rooted. -dylib_file is the flag you need. On many platforms -L is used to search for symbols in dependent shared libraries, on darwin, the install_name that is encoded into the shared lib is the method that is used. If the dependent shared library is not yet installed then you have to use the -dylib_file flag. This email sent to site_archiver(a)lists.apple.com

1 0

Re: linking shared libraries with dependent shared libraries
by Peter O'Gorman 13 Oct '04

13 Oct '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com User-agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) Paul Forgey wrote: e.g.: shlib1 shlib2 depends on shlib1 exe depends on shlib2 How about telling you to read the manpage for ld(1)? :-p Hope this helps, Peter -- Peter O'Gorman - http://www.pogma.com _______________________________________________ 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'm trying to port our product to OS X/Darwin. It makes heavy use of shared libraries and it currently runs on Linux and Windows. On OS X, I'm using twolevel_namespace. As the shared libraries are built, they are output into a common directory across the source tree. This allows the ELF targets to find dependent shared libraries as needed while either another shared library or an executable is linked. On OS X, I can't figure out how to get ld to search the same directory shlib2 was in to find shlib1. With Windows this doesn't matter since the DLL worries about other dependents at load time. With Linux, ld searches the same directory. I know I could work around this by explicitly linking shlib1 to exe. However, this is very impractical because it would make the build process very clumsy. Not only would the developer have to play detective to find out what the entire dependency tree is, but the entire build tree would have to be gone through if a heavily used library changed its dependents. Don't tell me to use frameworks. This isn't a Darwin-only project. -dylib_file is the flag you need. On many platforms -L is used to search for symbols in dependent shared libraries, on darwin, the install_name that is encoded into the shared lib is the method that is used. If the dependent shared library is not yet installed then you have to use the -dylib_file flag. This email sent to site_archiver(a)lists.apple.com

1 0

linking shared libraries with dependent shared libraries
by Paul Forgey 13 Oct '04

13 Oct '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com e.g.: shlib1 shlib2 depends on shlib1 exe depends on shlib2 Don't tell me to use frameworks. This isn't a Darwin-only project. _______________________________________________ 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'm trying to port our product to OS X/Darwin. It makes heavy use of shared libraries and it currently runs on Linux and Windows. On OS X, I'm using twolevel_namespace. As the shared libraries are built, they are output into a common directory across the source tree. This allows the ELF targets to find dependent shared libraries as needed while either another shared library or an executable is linked. On OS X, I can't figure out how to get ld to search the same directory shlib2 was in to find shlib1. With Windows this doesn't matter since the DLL worries about other dependents at load time. With Linux, ld searches the same directory. I know I could work around this by explicitly linking shlib1 to exe. However, this is very impractical because it would make the build process very clumsy. Not only would the developer have to play detective to find out what the entire dependency tree is, but the entire build tree would have to be gone through if a heavily used library changed its dependents. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Compiling IOHIDFamily?
by Felix Kronlage 11 Oct '04

11 Oct '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 11, 2004, at 06:54, Kevin Van Vechten wrote: just for the record (and the archives): # cd /tmp/PowerManagementHeaders / # pax -rw . / would be the pax-equivalent. iD8DBQFBao56DTGb09msdNARAtGyAJ9v0AWt2ZiR4acOI1Xol2Ly4y3KGwCeJLM9 sNnZIAFYBlbzFNlQEKSQFzs= =2n+a -----END PGP SIGNATURE----- _______________________________________________ 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… # ditto /tmp/PowerManagementHeaders / [If you're on a pure darwin system, you'll need to use pax(1) or tar(1) instead of ditto(1)] - -fkr - -- gpg-fingerprint: 076E 1E87 3E05 1C7F B1A0 8A48 0D31 9BD3 D9AC 74D0 http://fkr.hazardous.org/ | http://opendarwin.org/~fkr/ | FKR-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Compiling IOHIDFamily?
by Kevin Van Vechten 11 Oct '04

11 Oct '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ 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

Compiling IOHIDFamily?
by Steve Gehrman 09 Oct '04

09 Oct '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ 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