Good afternoon. My name is Kevin Van Vechten. I'm an open source software engineer with Apple. I'll be talking today about the core of Mac OS X, which is known as Darwin. It's a BSD layer, traditional Unix style. It's open source, and today I'll be talking a bit about where you can find the sources, how you can download them, and build them on your own system to make your own customization.

So first I'd like to talk a little bit about what's new at Apple. Last year, since WWDC, we've announced the APSL version 2 license. The majority of the code that Apple develops is released under the Apple Public Source License, known as the APSL, which was already an OSI-approved license, Open Source Initiative. Now it's also a Free Software Foundation free software license. So it's not GPL compatible, but it is recognized as a free software license by the FSA.

Also, we've unified the Apple IDs with our APSL registration, so the same Apple ID that you use at your Mac.com account for your iTunes Music Store, for Apple Developer Connection, can now be used to agree to the license to download these sources. And also, we had our Darwin 701 release, which corresponded to Mac OS 10.3 Panther.

So at Apple we have several open source projects. We have Darwin, we have Darwin streaming server, Rendezvous, HeaderDoc, the list goes on. Some really great technology that we have available that you should check out on our open source site. And the site that you should check it out at is development.com/darwin, the one listed up top. I'd also really like to strongly recommend subscribing to some of the mailing lists at list.apple.com.

These are lists where members of the community who are interested in open source can discuss various issues they're having. And there are also a lot of engineers at Apple who participate on these lists, who give responses to bug reports or general technical questions. Additionally, I'd like to point out opendarwin.org. Opendarwin.org is a mirror of the Open Darwin website. It's a very useful tool.

It's a very useful tool to help you get the resources available at Apple, and also hosts various other open source projects that are related to Mac OS X, such as Darwin ports. There's also close collaboration with the Fink project, both of which the URLs are listed here. And those two projects bring a large number of third party open source applications to Mac OS X.

So what you'll learn in this session is what's in Darwin and where you can get it, how to build most of the projects that are in Darwin. They tend to follow a common format. And we'll go over the best practices for building these sources. And also how you can use these projects on a Mac OS X system.

And specifically, I'll be talking about what things are generally safe to replace on Mac OS X with your own customized versions, and what things you should probably avoid replacing even though they're open source. And finally, I'll go over a brief outline of how you can make a bootable CD that has Darwin on it, which might be useful for an open source project, might also be useful to come up with some sort of Unix recovery CD for your own development purposes.

So Darwin is the open source core of Mac OS X. At the lowest level, it's the kernel. On top of that is I/O Kit libraries and families, I/O Kit drivers, and finally, it's the BSD commands and libraries, anything that you have access to from terminal.app or Xterm. And Darwin can be very helpful to you as a developer.

It's a place to look for reference sample code. So for example, a lot of the new work you've been hearing about in the past couple days has had to do with the new kernel programming interfaces and finer grained locking in the kernel. You can check out the sources to see either the MS-DOS FS or WebDAV FS as an example of these new locks in use in Tiger. And those sources are on the website.

You can also use these sources to debug your projects. Perhaps it would be helpful if you added a K print into the kernel at a certain step because the driver you're riding is having issues. It really lets you debug from the inside and see both sides of the picture when you're debugging your programs.

You can customize your system. Perhaps there's a feature that Apple doesn't provide, but there's a patch against Perl or against Python or any other open source component. It's possible for you to download the sources, apply the patch, and then get that feature on Mac OS X. And of course, there are also a lot of research opportunities, whether you're interested in machine virtualization or whatever. There's the ability to tinker with the underpinnings of the operating system and try new things out.

So I'll go over a brief history of Darwin. Darwin was first released as a bunch of images of the sources of portions of Mac OS X Server 1.0, and that was over five years ago. Since then, we've had a Darwin release that corresponds with each major Mac OS X release. You can notice about halfway down the list, there was a break in the numbering from Darwin 1 series to Darwin 5, 6, and 7. We have the Darwin versions match the major number in the build number of Mac OS X, so there's some consistency now.

You can see, you know, Mac OS 10.1 had a build number that started with a 5, and Darwin 5.1 was released. Panther had a build number that started with a 7, and that's also Darwin 7. So you can generally match things up using the build number and the Darwin number.

So you can get Darwin from the open source website. The main link for a lot of text on Darwin is developer.apple.com/darwin, which I mentioned earlier. But the actual sources live on the www.opensource.apple.com server. They're also mirrored at darwinsource.opendarwin.org. We organize the sources by Mac OS X release. So for each release, there's a page that has a list of all the open source projects. There's the name of the project, the license that it's covered under, whether it's the Apple public source license or another license. And then there's also a tar archive that you can download of those sources.

So there's also a neat trick for getting all of the sources. If you want to grab them all at once, you can go to the OpenDarwin site, and they offer anonymous rsync access on the Darwin source files. So this is an example command up here, where it's grabbing all of the sources that correspond to Mac OS X 10.3.4. You could change the version number to a different version and grab those sources instead, and the details are available on the OpenDarwin site.

So now I'm going to talk about building the projects that are in Darwin. At Apple, we have a proprietary build system, the 10 build system, and it's fairly heavyweight, and deals with a lot of issues related to building Mac OS X. And a lot of the projects that are in Darwin are customized to be built with this build system. Unfortunately, it's not practical to have this available outside of Apple, and so what we'll be talking about is some of the expectations that these projects might have that the 10 build system provides, and how you can set up your environment to build projects in the same manner.

So before you start, it's important to realize that there are a lot of variables involved in building software. There's the compiler tool version you have. We have GCC 295, GCC 3.1, 3.3, and now 3.5 with Tiger. So it's important to build sources with the correct set of compiler tools.

Generally speaking, the version of the compiler that was used to build a given Mac OS X release is the same GCC compiler that was shipped on that X release. So for anything in the Panther series of software updates, you'll want to use the GCC compiler that came on the developer tools accompanying Mac OS 10.3.

It's also important to realize that the environment variables in your shell have a large impact on how things get built. There are variables like the C flags or LD flags, which pass extra arguments to the compiler or to the linker. So if you don't want them to be set, be sure to unset any unnecessary variables before building, because it can change the results of the build. It's also equally important to set the correct environment variables that the projects might be expecting, and I'll talk about those in a minute.

The libraries and headers that you have installed on your system are also important. That's what the projects are going to link against. And so it's always important to keep in mind what versions you have installed on your system. And when you're building these projects, they will use them. And they will use those versions.

So if you are anticipating deploying the project to a different machine, you probably want to build on something like 10.3 base, and it would have the most compatibility over all the extra software updates. If you build on something later, like 10.3.3 or 10.3.4, it might pick up some changes that may or may not be backward compatible. So it's, generally speaking, easier to be forward compatible than backward compatible.

Another issue is, for example, the file systems. With 10.2, I believe it was, dev random was introduced. Well, if you're targeting a piece of software prior to 10.2, dev random is going to be there, and there's not much you can do about it. Likewise, if you're building software for 10.2, and you're on 10.1, dev random's not going to be there.

So if you have an autoconfigure script that's automatically detecting what features are available, it's not going to know that your system you're targeting should or shouldn't have dev random if the system you're on differs. So again, it's just really important to be building on the same style of system as you want to ultimately use the project on.

So the overall requirements for building software are generally more RAM is better and more disk is better. Obviously you can build sources with less than these requirements, but generally speaking, having about 300 megabytes of RAM will keep you from swapping a lot as you're doing large builds. And if you intend to build a lot of projects that are in Darwin, I recommend at least two gigabytes of space to work with. A lot of the intermediate files during building can take up a lot of space. And it's always unfortunate to see a very long compile die because you ran out of space.

On Mac OS X, while you're building, it's important to have the developer tools installed. Obviously, you'll need those to have the compiler on the system. But it's also important to have the BSD SDK and the X11 SDK installed. I think I skipped an item. The BSD package on the CDs, I believe it's defaulted to install these days. But in the past, it may have been an optional install. So make sure you have all of your BSD command line tools, because a lot of the sources require those to build properly.

So another important issue is many of the sources may rely on a case-sensitive file system. For example, the CVS project uses lowercase CVS to denote the executable and a lot of the sources. But it also is checked into CVS, and so there are uppercase CVS directories on the file system. Because of this, it's recommended to do all of your building on a case-sensitive file system, whether that's UFS or HFSX.

And I find that disk images work particularly well for doing this on Mac OS X. On Darwin, unfortunately, disk images aren't available, so it will be necessary to use a separate partition. Shown here is an example command to HDIutil, which will create a 4 gigabyte HFSX volume. So that has all the speed and journaling advantages of HFS, but it's also case sensitive by default, and allows you to build something like the CVS project.

Next I'll talk about the shell environment. Many of the make files that are used by these sources expect certain environment variables to be set. Apple's build system sets four very critical environment variables, and these are the source root, the object root, the symbol root, and the destination root.

The source root is simply the absolute path to where the sources are that you are building. The object root is a path to what should start out as an empty directory, and that is where all the intermediate .o files and other miscellaneous intermediate files will be stored during build. And it's possible to just delete that directory after a build succeeded.

The symbol root is where debugging versions of any executables, libraries, or drivers you build will be placed. And those versions have all of the symbols in them before the symbols get stripped out. And finally, the destination root is the final packaged bits. It's possible to take a destination root, package it up with a tar archive or something of that nature, and then install it on the system that you want to run the software on.

It's important to create all these directories before you begin building, since some of the make files won't create them, and then the building might fail because the directory is missing. It's also important to avoid spaces in the path names leading up to these directories. If you have spaces and there's a bug in a make file and it decides it wants to wipe out the object root, well, you might have some unfortunate consequences. So really be careful and don't use spaces in these path names.

Finally, it's important to change each of these to root wheel ownership. That way you get the proper inheritance of the root wheel user ID and group ID in the destination root. Many of the projects only change the root wheel. It's important to change the root wheel. It's important to change explicitly the ownership of files that it expects to be different, and so it relies on this default while you're building.

So when building projects, many of the projects have a make file. And if there's a make file, you should default to using GNU make to project, as that's what Apple does. If there is a PB proj or an Xcode file, then you'll need to use Xcode build, which is a command line tool that can build the project.

It's important to always build as root. As I indicated, some make files will change the ownership or the permissions of a file. And the only way to change ownership, at least now before there are ACLs, is if you have root privileges. So always be root when you invoke GNU make or when you invoke Xcode build.

And there are two main targets for each of these projects. There's an install headers phase. And the install headers phase installs only the header files. So if you have a big library or an I/O Kit family, and you're missing the headers on your system, you don't need to build the entire library to get the headers. It's possible to shortcut to just do the install headers.

That'll give you the headers you need for that library. And then you can move on to the next project that you want to build that requires those headers. On the other hand, if you use target, it will build the entire binary or library, et cetera. And that is the complete package of man pages, headers, and binaries.

For example, here's the basic environment for the ccTools project. Now, in Mac OS X 3.4, ccTools is version 495.8. And we'd find that just by going to the Darwin site. So now we can create directories as each of these variables point to. And the sources to cctools4958 should be in that path that's specified.

There are more environment variables that you should set. There's a project name, which is cctools. There's the project's source version, which is 4.95.8. There's the build version, which is simply the number of attempts you've made to build this particular software. This is our first attempt, so it's build version .

The architectures are what architectures you're planning to build for. For Mac OS X, that's obviously PowerPC. Darwin actually supports both 386 architecture and architecture, so you might add in that flag if you want to. Kevin Van Vechten The operating system flag for environment variables is always Mac OS. The release should be whatever release you're building for. So since this is CC Tools from 10.3.4, you'll want to specify a release of Panther.

For path releases, 10.0 is Cheetah, 10.1 was Puma, 10.2 was Jaguar, 10.3 is Panther, and 10.4 will be Tiger. The Mac OS X deployment target will affect how header files are interpreted, and it should be set to the version number of what you're targeting. It shouldn't include a software update version. I believe it should just include the major version, so 10.1, 10.2, 10.3, or 10.4.

For Darwin, as I mentioned, there are a couple of variations. You may want to include the i386 architecture while building. You may want to include extra C flags. For example, Darwin does not have the C preprocessor, so we're specifying -node-cpp-precomp. So the CppPrecompiler doesn't get run. And also, the release is not Panther or Tiger, but the release is simply Darwin when building Darwin sources.

So, to actually build CC tools, we set the environment variables, and also pass all of those same variables as additional arguments to the make command when we're building the sources. It's also very useful to redirect all the output to a log file. Many of these projects have a lot of output while they're building, and if something goes wrong, your scroll back history might not cover it. If it's in a file, you can go back and see where things actually started to go wrong.

So, in this example here, doing C2-S, which makes everything run as root. Again, that's very important for building the sources. We're doing a make install of CC tools, PowerPC architecture. I show the source root and the additional variables we went over omitted for brevity. The bottom left-hand corner, I'm redirecting standard error to standard out. So, both standard error and standard out will get captured in the same. And then I'm storing it in a log file that you can see there.

So I'm going to do a little demo now of going over the steps of building CC tools that we've just discussed. So here I have the command for HDIutil. We'll create-- I guess for speed, we probably don't need a full two gigabytes. So we'll create a disk image quickly, and this is where we'll be doing our building. This is an HFSx disk image, so it has case sensitivity.

So I've chosen a name of build root for this example. And I'll change into the build root volume. Now I've already downloaded the CC tool spaces. So what I'm going to do is extract them. All the sources we publish on the site already have a directory name of the project name dash project version, so that's already set up. You can just extract it to wherever you want to build the sources, and you're ready to go.

So I already have a little script here that sets up the appropriate environment variables for source root, object root, symbol root, and dest root. It creates the directories to make sure they exist before the building begins. to wheel for each of those all the environment variables that were discussed. into the directory where the sources are. We make install, because we want to build the whole thing. And again, all the variables that we had set in the environment, we also want to pass as additional arguments to make.

So now we are running as root, and I'll do --x, which basically tells the bash shell to echo each of the commands that it's running, so we can see step by step as we run through the . I'm going to be working on this for a little while.

So now is the time to talk about dependencies. Come back to the build, it will and there will be an error that streams.h was not present. Basically what happens is there's a lot of that aren't shipped on Mac OS X because they're not needed for day-to-day use. But they are available for the open source website.

So right now, it's not easy to determine where the streams.h file may have come from. We're working on some that can help track that type of information down. We're searching through the Darwin source. So the next step would be to go to the open source site,

Once we have that, we can take the build result, which has, we'll call it a root, that contains all of the build results of the Libstream's install headers, and we can copy that to the base system.

On Mac OS X, the ditto command is very useful for copying one directory to another, so you can just ditto from the directory that contains the Libstream's headers to slash, and that'll copy everything to the correct place. If you run it as root, it will also reserve all of the permissions.

So, you always make backups. Obviously, if you're going to be copying files over your base system, something can go wrong at times, either if you don't have a build of something you expected you did, or versions don't match up. So, it's important to have good backups when you're building these builds.

On Darwin, Ditto is not available, but either the GNU/TAR or the Pax command can be used to copy the sources to the root. So, I have a couple example usages of both Ditto and of Pax shown here. We're going to go back to the demo to resolve that streams.h problem. So we can see here that streams.h was not found, and we have an install error. I also have already downloaded Libstreams project.

So I'll extract the resources now. script set up to compile. We're doing the same steps, setting the source root, the object root, the symbol root, destination root. We're creating the directories in case they don't We're changing the ownership to root wheel. We export the project name, version, and the different build Not only do we export them in the environment, but also pass them to the Make file. Though, in this case, instead of Make Install, it's Make Install Headers. We just cut the header.

So installing the headers is actually very fast. You just need to copy a few files into the destination route. And if we look at the directories we have here, If I find all the files that are in the libstreams, we can see the libstreams, and then user local includes streams.h and streamsextra.h. So this is what you might expect into the base system to satisfy that missing dependency on streams.h. And we'll use the ditto command.

We can see it go a little farther. is a lot of times when we do a build, the object root has results. The next thing is one of my best practices that I didn't follow. It's a good idea to clear out the object root and the symbol root.

from there. We'll get everything from there. This time, hopefully, it'll get a little further because we

So again, be careful. Always back if you're changing anything on your base system. It's also important not to overwrite the core foundation The Core Foundation is an example of something that doesn't quite match up between Darwin and Mac OS X.

It's a lot of extra functionality in Mac OS X that's not present on Darwin. So if you were to replace it on your Mac OS X system, things would fail to work. In general, the BSD commands and the BSD libraries are safe to replace. So those you don't need to worry about too much. But XNU, it's also generally safe to replace. But since it is the kernel, any mistake will leave the machine unbooted. It's always good to have a or a CD or something you can boot from again to restore your backup of the kernel.

I/O Kit drivers and families have those same set of concerns. Basically, it's the base of the system that decides where the system will boot or not boot. You really have to have a backup. If you have an extra partition that has a full system on it, of course, when you're booting, you can use the Option key to select which partition you want to boot from.

So if something goes wrong on your building partition, you can use the Option key to go back to your backup partition, boot from that, and then correct any problems that you may have had. Generally, for troubleshooting, remember, it's important to build this root. Things won't fail out, but the risk to change ownership might fail silently. And so the build results you get won't be exactly what you were expecting.

As we saw, a lot of times it's necessary to clear out the optimal route, and even the desperate route, after each attempt to build the software. If there are intermediate results in there, sometimes the Makefiles aren't as robust as they could be, and they will go any further, because they were tricked by a file that's in there. So clearing those out gives you a fresh start, and it usually makes things succeed.

If there's a header file missing, you can use the install headers phase to shortcut a build. And of course, if you have specific questions, don't hesitate to ask a mailing list. The [email protected] is a good general starting point for Darwin questions, and there are more specific lists for kernel technologies or other areas of Darwin. And also at Darwin.org, [email protected] list, where people who are involved in the Darwin source code discuss .

Next I'll talk about a little bit more advanced topic, building in a changed root. A changed root is when you use the change root BSD command. There's a good man page available on it that describes a little bit about what it does. And what essentially this does is it changes the root directory, slap, to be a different subdirectory on your disk. And the advantage to doing this is it's now possible to install headers and install libraries, compilers, whatever you need in a different environment than your host system.

So if something goes wrong in there, it's less likely to affect the partition that you're booting off of. And it's also possible to, or more easy, targeting a system that's different than what you're running on. For example, if you're running on 10.3.3 or 10.3.4, because that's what's newest you want running on it, you'll want things to work on 10.3. And building up a changed root with the 10.3 stuff will solve the problem. The problem of picking up libraries and headers might not have been present at that time because you're in a more self-contained environment.

A couple of things to note though is that this doesn't change IPC. So it's still important that you use the same major version. Although it's easy to do a change route to build 10.3 sources on a system that's actually 10.3.4, things inside the change route will communicate with the various daemons on the system, like lookupd. So if there's been any protocol change, the change route doesn't reflect that, and things either might fail to work or get unexpected results.

So here I have an example script. Again, you have to be root user to the root of the file system. And when you change the root to the file system, some things will be missing, like devfs. And a lot of software needs that to compile. So here I have an example of creating the dev directory in the root that we're going to change into, mounting the devfs file system on that dev directory, mounting the file descriptor file system on top of that dev directory as well. So that gives you things like /dev/null, devrandom, the various file descriptors that are accessible from the shell.

And it's important to mount these file systems outside of the change root. If you mount them inside of the change root, then it might not be possible to unmount these file systems until you restart. However, if you mount them before changing into the root, then it's possible to unmount them again. So here we changed the root once this has been done. And that will drop us into the default shell inside that root directory.

I'm going to talk a bit about the Darwin build tools. The Darwin build tools are scripts that I've developed recently that help to automate some of these tasks I've just discussed. So as you might imagine, it would be fairly obvious if you had to type in all of the text each time to set all the environment variables and pass all those same arguments to make. And these scripts automate some of those processes.

The Darwin build tools are two main components. There's the Darwin cross-reference tool, which is called Darwin XRef. And what this can do is download a property list from the OpenDarwin site or Apple site, and these property lists will be hopefully available soon. There's an example one that is available already with the tools for 10.3.4.

And these property lists allow you to look up what the particular source version is for any project that's in Darwin that corresponds to, say, Mac OS 10.3.4, for example. You can also list what projects that depends on. So in order to build CC tools, we saw that we need to first have the headers of libstreams, and that information is reflected in the Darwin XRef. So the Darwin XRef tool is a very generic tool, and it's possible to ask that tool for a list of those types of dependencies.

And then another function that the Darwin XRef tool has is the ability to cross-reference which files are installed on disk with which project they came from. So for example, if we see that streams.h is missing, We can run a little query on the Darwin XRef tool, and it will report back that libstreams is the project that that came from. And again, over time, this information will be available for the Darwin projects. The Darwin build script is a script that actually sets up the environment. It uses the Darwin XRef tool extensively to get the correct source versions.

sets up the environment for building. It also does a little bit of automatic fetching of the dependencies. So if you don't have libstreams already, it'll go look on the OpenDarwin site and try to download it, for example. And it also helps automate change-routed building, so it will create a directory.

It'll load up all the routes that are needed to change into there, change the route, perform the building in that isolated environment, and then the building succeeds to copy those files out of that isolated environment into a place that's ready for you to use. So here's some example usages of the Darwin XRef tool. And again, these tools are available at darwinsource.opendarwin.org.

Up top we have Darwin XRef and we load the index. So we're taking build 7H63 was Mac OS X. It's a plist we downloaded from the website. We load it into the Darwin XRef tool. Then we can do queries. The first example is asking what version of the born shell was included in X. And it says that was source version 29.

Next we can ask it to find file streams.h. And it notes that libstreams project installs a file that's in user local include streams streams.h. And finally we can ask it what are the runtime dependencies for the born shell. And it knows that the born shell requires libm, libsystem, cctools, and the library in order to run. And there are other dependencies which I don't have listed here.

The Darwin build script, as I mentioned, will download sources from the Darwin source website. So it automates that step for you. However, if you already have them on your local system, it'll use those. Or if you're modifying the sources, it checks the local system first. That's where you can put your modified version and have it build.

up the proper shell environment. It saves roots and the symbols from a successful build in a directory hierarchy that's well organized and ready to be used. And it also installs any dependencies into a root before changing into it to perform the building. So a couple examples here, we can install the header files that are associated with the kernel by issuing the command darwin build dash headers XNU. To do the example we just went over, we could have done darwin build dash headers libc.

And another example is building the standard C library, libc, in a change root, and that's as simple as doing darwin build dash change root libc. So now I'm going to demo those Darwin build tools. Thank you. So we already have our build root directory. I'll get rid of that echo. So we already have our build root disk image, but we don't need any of the stuff that's already on it. So I'm just going to wipe it away.

So what I'm going to do now is install the Darwin build tools. So these are available on that darwinsource.opendarwin.org site. And there's a README that is on the site and also included in the TAR archive that explains how to set this up, including creating the disk image and doing the installation.

But I'm going to install this onto that build root image. And here it creates some directories. It creates sources, objects, symbols, headers, and roots, and logs. These are where the various results of your building will be stored. So after sources are fetched from the open Darwin site, they'll be stored in the sources directory. After the build has finished, the symbols go in the symbols directory. The headers go in the headers directory. The roots go in the roots directory. and the log of the build is stored in the logs directory.

The first thing we need to do is look up the Darwin cross-reference tool. So I'll load that up with the sample property list that's included. And you can see there are 313 projects listed in this property list. So as the example I gave, we can ask for what the version of Bash, and it was Bash 29, that's in the current system's build. If you have other plists that are of different build numbers, it's possible to add extra arguments to the Darwin cross-reference tool and have it consult one of those other builds that might be different from the system that you're already on.

So here, we may want to build all of-- well, let's just do Bash, for example. You can see it's fetching the sources. It attempted to download them. It succeeded. And it's going through and doing all the compiling. It prints out some information about the local computer, such as what version of GCC is installed, what version of the installer is installed.

It also tells you what values it used to set up the shell environment variables, what all the environment variables that were currently set on the system are. What command it used to do the build, and then it goes into a log. Here's configure, and now it's actually going ahead and building some of these sources.

So I'll kill the building there for time. But we can look in the logs. And sure enough, we have a log. This is the Bash project, source version 29, attempt number one. All of that output that I was just showing you has been saved into a log file. So you can go back and review that at a later time.

Now I'll give an example of the change-rooted building. It has the ability to download some of these pre-built routes from opendarwin.org, but in the interest of time, I already have them on the local disk, and I'll just copy them over from there. So this is a collection of pre-built projects.

Now, the environment that's used to build is all stored in this Darwin build ENV file. And again, all these details are available in the documentation associated with these tools. But since we'll be building a Darwin project, let's say for fun, that I want to enable the 386 variants of the architecture. So here what I've done is I've changed around the variables so that not just PowerPC is specified, but also 386 is specified.

And I can do a Darwin build. Now, by default, Mac OS X does not ship a 386-labeled compiler, but it is part of Darwin. So to prove that we're changing the route here, I'm going to compile Bash, as we saw for 386 and PowerPC in this change-route environment. So what it's doing right now is installing those routes, which can be downloaded from Open Darwin, or as we see here, they're already cached on the system. And it's copying all of those into the build root directory. So first it installs all the libraries and binaries that the-- oops.

Maybe I can give a different example. So as we can see here, at least, though, the PowerPC and i386 architectures were specified. It did compile those architectures in the change root environment. Apparently, I still need to work a little bit more on specifying the dependencies in the property list file.

But if we look in the build root directory, you can see it's a mini version of the redirect that you might expect with directories like bin and sbin, user, applications, developer, et cetera. And also, as I mentioned with mounting the developer file system, devfs is, or the device file system, sorry, devfs is in that change root environment. Amen.

So that's the demo I have of the Darwin build tools. I'll be going back to the slides. I'm now talking about creating a bootable CD. So it's possible to collect the Darwin projects, install them onto a disk image, and then burn the disk image and boot your computer from that.

For the sake of simplicity, I'll be talking about using the HDI utilities to burn the CD, which can only be done on Mac OS X. There are steps for doing this on Darwin, which you'll be able to find on the Open Darwin site. The first step is to create a CD image using the HDI utility, and that shows up as an icon on the finder.

Then you want to copy over the various projects that are needed to boot the computer. Few finishing touches that need to be done, which I'll go over, include choosing a BLEST directory, which helps the open firmware on the computer boot from the CD, as well as creating the text cache, which all of the dependencies of the kernel .

And finally, you'll burn the CD image. So the first step in creating a bootable CD is to use HDIutil. In this example, I'm creating a 650 megabyte disk image on an HFS partition. I've given it a volume name of Darwin. And this will do the normal process of creating a disk image. And then we can attach it. And that's when the icon will show up on the desktop, and you can change into the directory from terminal.app, et cetera.

It's important to set the ownership of this new volume to root wheel. Again, if we're going to be copying a bunch of files into it, you want the right default permissions. So start off with root wheel, and do all the copying as root, so that all the ownership can be transferred.

You can use the ditto command to do the actual copying. It's important to copy the files project first. That project is what has the directory hierarchy of a Mac OS X system. It's what creates the user directory, or the bin directory, or the applications directory. And so it's a good base to lay down. And then all the other projects will start filling in those directories with their executables and with their libraries.

It's important to copy the kernel, bootX, which is the bootloader, libm is the standard math library, libsystem, cctools, which includes the dynamic linker, startup, the ncurses library, bash, so you have a shell once you've booted, various file commands such as cp, rm, the ones that you're used to, shell commands, and the list goes on.

Kevin Van Vechten This will change for release to release as things move around. We'll try to keep some information about it on the OpenDarwin site, but these are really the core projects that for any release you absolutely need to have on the CD. Again, there are others that you probably need to have or will want to have on your CD to make it more useful.

So the next step is to bless the CD image. It's a command line tool called Bless, which has an excellent man page, so I suggest reading that. And what that does is it sets a special bit on the CD that lets OpenFlare know that this is a CD that can be booted, and this is the bootloader that should be used. So in this example, we will bless the folder that's the Courses folder, and that's where BootX installs its image.

We also specify a label is actually the name that appears on open source. It's a little image that's pre-calculated. When you do a partition, if you set the label up, it's "An easy to read name when you hold down on your computer to decide what you want to boot from." The first step is to generate the mkext cache.

The cache is basically pre-computing all of

may report a few missing dependencies or some things of that nature. This is a normal, so one or two extensions of the Don't worry too much. a large of it, and then perhaps something important is missing. And generally what you'll want is you'll have a similar set of extensions in this folder as well as what you're using to boot the... I also want to create a startup script by default, these Darwin

"What you want to do is have a little basic commands and drop

I assume that it does.

If it doesn't, different instruction on that. So here what we can do is we can make a directory called which lets script as an installer CD. at CECD, which go and execute that file startup. And we have the opportunity, which will put us into the . And that's really all I wanted to do today.

For more information, contact Jason Williams, the CSI's IT manager.