Re: three things I stumbled onto while building xnu-792.17.14
Re: three things I stumbled onto while building xnu-792.17.14
- Subject: Re: three things I stumbled onto while building xnu-792.17.14
- From: Terry Lambert <email@hidden>
- Date: Wed, 2 May 2007 21:01:58 -0700
On May 2, 2007, at 6:59 PM, email@hidden 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-).
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.").
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.
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.
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.
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.
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.
A third issue is with using the latest GNU make-3.81+.
If you are complaining about the "powerbook option deprecated"
message, ignore them. 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.
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.
-- Terry _______________________________________________
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