site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed 02 May 2007 23:01:58 -0500, Terry Lambert <tlambert@apple.com> wrote:
On May 2, 2007, at 6:59 PM, sci-fi@hush.ai wrote:
Hi,
Stumbled onto three things while trying to build xnu. Let me split them up; they really aren't related to one-another...
....
I'm just curious. What would it take to fix xnu to be able to
use
gcc-4.0?
Building the gcc-4.0 compatible sources. 8-).
well blow-me-down why didn't *I* think of that :p
This is the first error I hit:
[…] /Users/scifi/Projects/xnu/xnu- 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp: In member function ‘virtual bool IOWorkLoop::init()’: /Users/scifi/Projects/xnu/xnu- 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp:79: error: converting from `IOReturn (IOWorkLoop::*)(void*, void*, void*, void*)' to `IOReturn (*)(OSObject*, void*, void*, void*, void*)' in a kext. Use OSMemberFunctionCast() instead. /Users/scifi/Projects/xnu/xnu- 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp:93: warning: invalid conversion from ‘void (*)(void*, wait_result_t)’ to ‘void (*)(void*)’ /Users/scifi/Projects/xnu/xnu- 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp:93: warning: initializing argument 1 of ‘thread* IOCreateThread(void (*)(void*), void*)’ […]
Download the xnu-792.18.15 (x86) sources instead of 792.17.14 (ppc); all these issues are fixed there by doing what the compiler is telling you to do in the error message ("Use OSMemberFunctionCast() instead.").
If this is Apple's official stance on this, then I will try it. But later in your reply below you seem to contradict yourself here. I will put the rest of my comments on this down there.
Could we use a -std= option or something similar to let gcc-4.0 handle IOWorkLoop.cpp line 79 as gcc-3.3 would have?
No.
The reason I'm asking is that I'm very keen on wanting to try testing optimisations only available with gcc-4.0 such as - -ftree-vectorize (a very important one).
You will likely be unhappy with this particular option, since vector registers are not spilled in normal context switches in kernel code (e.g. between the kernel thread and interrupt context). They are
spilled for KEXT calls, but not for the kernel itself, so you will be corrupting registers all over the place. This is supposed to be explicitly disabled when building a static binary (like the kernel) because of this.
I understand this. It goes without saying. I'm hoping we can work on this. It's one of those things I do: push the envelope. If ppl _are_ working on this, then I hope this list would be the proper place to rendezvous with them, and here I am saying I'm very interested in helping. Hey if no one pushes these concepts further, I feel they'll never get done. Although not exactly akin to PPC+Altivec, I've had some experience with FreeBSD/x86 kernels, and they've been able to insert some MMX/etc. optimisations down into their code. About time we try raising G4/G5 to match that level. If no one works on it, how will it ever get done. So maybe I'm the lone wolf on this… I hope not…
A second issue with xnu is that it uses "echo -n" quite a lot in the scripts -- this is not supported by the latest bash-3.2.x, producing some very strange "No rule for" errors. This is actually a very common problem with many many projects all around the world. Most scripts will perform a test (a) for whether echo needs the -n, or (b) does a \c need to be added to the string to be echoed, to prevent the automatic linefeed. With xnu, I've simply replaced all plain echo cmds with /bin/echo or coreutils /usr/local/bin/echo both of which do support the -n.
This is a bug in /bin/echo which I will unfortunately have to try to get fixed, now that I know about it (i.e. the "-n" option is _NOT_ supposed to be supported). See:
<http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html>
"On XSI-conformant systems, if the first operand is -n, it shall
be
treated as a string, not an option."
So this is supposed to not work the way you want it to.
Not "me" -- whoever wrote those scripts for your tarballs. ;) Again I'm pushing the envelope since I'm purposely staying current with bash, ncurses, auto* tools, coreutils, findutils, make, iconv, etc. etc. etc. (take a gander at the xfree86-devel list for the past couple weeks to see what we've fixed there). Again I feel it doesn't seem to be getting done otherwise (Fink and MacPorts are still rather back-level in many areas, let alone what Apple provides … and I detest pkg-mgrs, the project ought to be able to be built the normal documented ways, if not then we need to fix it … plus the pkg-mgrs *always* strip-out my own tweak settings e.g. CxFLAGS env-vars and such). I'm only reporting what needs to be fixed. I can only supply patches to the published source -- a long time ago we would have been able to do "cvs diff" against the live repo. btw for that matter I don't see xnu anywhere in MacPorts tree as a svn branch, neither are the prerequisite components. So I'll attempt to send the diffs via bug-reports but as I said I feel we aren't "in the loop" for affecting what gets fixed very much that way, so I use this maillist to shed light on the matter. The other half of this can only be done by filing bug-reports that request which components that need upgrading, that can't be done with patches, only with simple requests (e.g. "please upgrade the provided bash to 3.2.x" ;) ).
The current build system assumes that you will use a Tiger (or Darwin) system with the current tools installed in order to do the build.
From your description of running into this, you appear to be building on a Leopard seed, instead.
# uname -a Darwin SciFiG5.homeip.net 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc PowerMac7,3 Darwin As I mentioned before, I try to keep up-to-date with the various open projects. This does not mean I have Leopard installed here! btw I stated on this list in times past that I will never trust the "leaked" dmg's being spread on-line. I can't afford a $pay-for$ ADC account so I'm unable to help work on those projects in an official manner. I can only afford to help with what's free & open (*ahem*). (Someone here a while back said I should submit a proposal to get a paid-for ADC account maybe from a mentorship but he's not responded to my private reply.)
The fix for this is to modify the four lines in MakeInc.def, the one line in MakeInc.dir, and the one line in MakeInc.rule to use:
printf "%s"
instead of:
echo -n
...you will need to quote the entire argument list to make it into a single string.
oh yes that was the _third_ way some scripts deal with the matter, I'd forgotten about that… but it introduces yet another dependency.
NOTE: Building a PPC kernel from the Intel sources so that you can use the newer gcc is a totally unsupported PPC configuration, so if it blows up or gives you rabies, you're on your own.
Here's where the "help" I'm getting on this list is contradicted. Earlier above you said I should get the Intel sources, but here you say I'm on my own if I do. This is what I'd expect from M$, not from Apple. If Apple truly wants to support gcc-4.0 in this regard, why won't Apple "fix it" for _all_ machines it supports -- we are all having to re-invent the same wheel over & over & over again when this issue comes up, and this is why I feel bug-reports seem to go ignored. ~sigh~
A third issue is with using the latest GNU make-3.81+.
If you are complaining about the "powerbook option deprecated" message, ignore them.
I have no idea what you're talking about here, really.
Alternately, use Apple's "make" instead, or port Apple's patches forward using the GNU Make sources and the Apple supplied copies of the GNU Make sources.
Apple's gnumake is based on GNU make-3.80 which is terribly old now. 3.81 has tons of fixes and updates, and I am actually sync'd with their cvs version 3.81.90+. As I said last time, if you-all are interested in letting the GNU make team know that the Objective-C patches for make are important, then please send a comment to that savannah bug-report I mentioned last time, that's where we are tracking this issue. They are the ones needing convincin', and we need you-all to help convince them. I've already done my bit there. Please & thanks.
Yeah I could file bug-reports with Apple but boy they must have an avalanche already. (and no I can't afford to $pay$ for expediting anything…)
The MakeInc.* changes are benign, but unless there's outside demand (e.g. you file a bug report), you're going to have to keep building Tiger on Tiger, or do the patches by hand.
And as I keep re-iterating, the general feeling is that those bug-reports seem to go ignored for-ever & ever… surely someone has already reported these problems, they _have_ been in so many xnu releases for years, but we aren't privvy to see whether it _has_ been reported already nor what the statuses are for previously filed reports by others. So each separate person "who cares" will end up filing his own report, re-inventing the wheel again & again. I'm complaining about the bug-report "repo" itself -- Apple needs to open them up for public research like the many many projects based on e.g. "bugzilla". I'm sorry but this IMO is a public stain that makes some of us believe Apple really doesn't want to support open source very well. So I use the maillists to shed light on the issues we're having, taking them public rather than keeping them hidden in Apple's bug-report system.
-- Terry
Thank you for discussing this. It's not the end of it, tho, not until the issues are actually resolved. -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkY507IACgkQZbt5KOxKrtSTEQCffMTnisKxKjxI0kuOi6Idqn/wtvcA nj+QALorPc3KFsj6REMsbJ26eFh7 =IZWD -----END PGP SIGNATURE----- -- Click for home mortgage, fast & free, no lender fee, approval today http://tagline.hushmail.com/fc/CAaCXv1KZF8ZagbohAB2zJQlVkXIbfBT/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com