gmane.linux.lfs.devel

LFS SVN and Systemd Report

Armin K. — 2012-05-25T12:55:58

Hello there, I have just finished LFS+BLFS SVN (with software from LFS 
Trac too, including Perl 5.16.0, Udev+Systemd 183 and Linux 3.4.0).

I say LFS+BLFS since I installed some BLFS packages during LFS build. I 
did not want to complete everything and then install BLFS packages and 
possibly recompile some of LFS packages. But, never the less. Everything 
works. Also, I ditched sysklogd and used rsyslog for my system since it 
provides native systemd units.

I want to add that I've experimented with "the /usr merge" since I use 
one partition for everything.

$ uname -a
Linux lfs 3.4.0-krejzi #1 SMP Thu May 24 18:33:15 CEST 2012 i686 GNU/Linux

My hardware is an older Pentium 4 HT with 1024MB of DDR RAM.

After booting with basic software installed, I get
$ systemd-analyze
Startup finished in 1686ms (kernel) + 7995ms (userspace) = 9682ms

Currently running services are
http://paste.debian.net/plainh/14ddd735

Or if you prefer as ps output
http://paste.debian.net/plainh/504f9d4c

Memory usage with such services is as following
$ free -m
              total       used       free     shared    buffers     cached
Mem:          1007         25        981          0          0          6
-/+ buffers/cache:         18        989
Swap:         1080          0       1080

with lot of modules as shown here
http://paste.debian.net/plainh/ea7237d9

I saw that someone complained about mount output on some other systemd 
distro. Here is mount output from my installation. I needed to remove 
some useless mounts that I did not need like debugfs and such.
http://paste.debian.net/plainh/aa83f0f6

securityfs seems to be hardcoded into systemd binary. Others are cgroups 
which expose like that. Also, /tmp can be set not to use tmpfs if desired.

Since I don't even install LFS bootscripts package, I don't have any 
networking with systemd. But that one is simple ... Just executing 
dhclient eth0 brings up my interface. Also, I have created /etc/rc.local 
for local scripts so I could run some scripts from there at startup. 
(Found in Debian too).

If you are interested, here is dmesg output
http://paste.debian.net/plainh/5316e589

I don't have any build stats or such stuff, I needed 3 days to build 
everything, but with taking notes, making patches so I can install 
everything how I want with just one command.

So, is LFS still going to avoid systemd? I said on trac that it is not 
possible to install just udev from systemd tarball.

I've also discovered that udevd is now named systemd-udevd and located 
in /usr/lib/systemd (or /lib/systemd/ if not using /usr merge like me).

systemd also manages configuration of locale (/etc/locale.conf), 
timezone (/etc/timezone), hostname (/etc/hostname) keyboard and console 
settings (/etc/vconsole.conf). Note that vconsole setup is broken in 
default systemd installation since it starts before KMS and KMS resets 
console font and charset. I've hacked on it and set it to start after 
tty's have been spawned.

Regarding the dependencies, I've discovered that the following are minimal:

attr and libcap
expat and dbus
xml::parser and intltool

Also, if intended to use systemd-logind as consolekit replacement, 
linux-pam is necesary for pam_systemd.so.

Other deps are tcp wrappers (no idea), cryptsetup (for accessing 
encrypted volumes), selinux and audit (no use on lfs anyways, I've 
stopped using it).

Your move.

About packaging LFS - How it works for me 8)

Marius Tolzmann — 2012-05-23T00:00:52

Hi..

I was pointed to the "Once More: Package Management" discussion 
yesterday. So I just joined this list.

First I want to thank you for LFS. It's great. I love it. And i made a 
few more people love it, too. The same is true for BLFS.

I will start with many words about my LFS background 8)

I am using (B)LFS (as a reference) since (i think) 2004. After we had 
some serious issues adjusting a red hat linux to our needs I started a 
linux from scratch to finally have a linux that follow my rules 8)

I really learned a lot from this documentation - even if it wasn't very 
easy all the time.

When using an LFS based distribution in a production environment you 
have to do some kind of minimalistig package management. what we do and 
what we have done isn't really package management it is more about 
package tracking - to answer the important questions like which file 
belongs to which package? just to be able to install and remove a binary 
package after creating it following the (B)LFS Book(s).

Two years ago we were forced to rebuild the whole system - because it 
seemed to be easier to rebuild than to upgrade and solve the dependency 
hell.
The way we maintained our LFS based system between 2004 and 2012 worked 
wuite well, but was not really perfect: To document how a package was 
build we just scripted the steps to build it and executed the script, 
did some binary package creation and just kept the directory of the 
build as documentation. Our documentation was quite bad these days.
So when starting to rebuild our LFS based system I decided to do it 
better this time. I tried to find some package management software which 
was very easy to use, is highly configurable and helps me to document 
the build - just to make updating and rebuilding packages easier for us 
- Long Story short: I havn't found a package manager.

But lazy as I am, I started scripting some code together to help us to 
maintain the system. The goal was easy: 90% of the software is configure 
&& make && make install. some special options here - some patches there 
- some post install issues in some packages.
All those special options don't change much from one version of a 
package to another. So Reusing build-scripts was a main goal.
Since we are LFS based we want to stay as close to (B)LFS as possible.
So just cut & paste the LFS recipies would be great for us. After taking 
some time to think about our needs we started to implement something. 
The idea was to first have a solution for the easiest case:
configure && make && make install - no options, perfect software with 
perfect defaults - so we implemented something for the perfect world. 
And step by step we were forced to face reality and add more flexibility.

After Two years we have managed to have a working LFS based system - 
build with our own package system - which is used in production on many 
big servers and many workstations now.

So much for the background and our ideas. We just released our first 
official version of our tool to manage packages in our LFS based 
environment. I will not call this tool a package manager because it 
lacks some important features to call it so but i think it may be 
interesting for some of you to know it exists. It is not perfect - even 
it tries to be perfect so hardly - and it may have some (minor) bugs but 
it works (at least for us).

The name of our tool is BEE - an acronym for "bau et einfach" (which is 
german for "just build it" but it may also be an acronym for "build 
extremely easy".

What BEE can do:

In it's easiest form it can build a binary package directly from an URL 
pointing to a source tarball. And that is already the main feature. The 
user just has to know the URL. We tried, but we haven't found an easier 
way to create a binary package out of source tarballs.

bee binary packages are tarballs.. no fancy format..

Yes, this works for autoconf based sources and for cmake based sources 
and for perl modules and ... it just works.. it autodetects a lot of stuff.

And yes, you still have the possibility to change every single step in 
the build process. All BEE does is to create an initial (so called) 
bee-file which provides a basic structure of a generic build process.
(In fact it creates a script (bash) which has a lot of comments and just 
sets one variable: the SRCURL).

You can just add some shell functions to overwrite/expand the 
autodetected defaults with your own idea of how to configure the 
package, build the package, patch it or whatever.

Short: you can influence nearly every step bee does.

So it is easy to create bee-files for LFS packages that are in my 
opinion quiet close to what is described in the LFS book.

We already started a small proof-of-concept project where we provide 
some bee-files for the LFS chapter05 toolchain (the other chapters will 
follow when we find some time)

Why i don't want to call it package management:
You can install the binary packages you can update them or remove
them from your installation. Which is in fact some kind of management.

We don't provide support for remote repositories where you can get 
binary packages from. It is more intended to work as follows: You create 
a bee-file, you build your package, and you install it.
Local build, local package repository (some directory), local installation.

We don't provide config-file management (yet). We have some (cool) ideas 
how to solve this issue without loosing our main feature:
URL -> PKG.

But we don't provide any automated dependency resolution. And we don't 
plan to do this in the future.

But we plan to provide some information which can be automatically 
generated at buildtime about what packages the current package was built 
against. How the new package may break already installed packages.

We just don't have a solution how to fix the dependency hell without 
getting crazy. In my opinion, everything which needs to be done manually 
when trying to provide information about how to resolve dependencies 
will fail.

And we also don't support build-time-dependencies at all. Because there 
is nothing a test for the availability of build-time-dependencies can 
tell you what a failing configure can't tell you better. (And even 
worse: if a configure does not fail, it does not mean that all build 
time dependencies are satisfied - the make may fail later 8) )
Perhaps nobody will ever solve this - we don't try.

Ok... this is a very large first post.. 8) sorry for that.

just some quick bee examples:

the bee file for LFS chapter 5.4: binutils pass1 [1]:
   (comments and some other stuff removed, original file in [2])

Vim 7.3.xxx

Fernando de Oliveira — 2012-05-19T16:19:10

I am posting this to two lists because Vim is common to both. Of course, discussion and opinions, if any, could be different in each one.

While some softwares are rushing new versions even weekly, others stick to a "main" one and leave the minor versions/corrections in their repositories to be checked out with git or other softwares, and this is the case of Vim and MPlayer.

I have noticed that most distributions are changing to upgrade these more often, perhaps monthly.

Some examples with Vim:

*buntu                       7.3.429
ArchLinux                  7.3.515
Fedora                       7.3.515
Gentoo                      7.3.515
Mageia                       7.3.444
Mandriva devel           7.3.486
openSUSE Factory     7.3.456

Sometimes, they call it version 7.3 "correction-xxx".

MPlayer has already changed. What do you think about Vim in LFS and/or BLFS, with a monthly source in Anduin?

Once more: Package Management

Jeremy Huntwork — 2012-05-19T13:26:31

I've been holding back bringing this up on-list for a while because I 
intended to do the bulk of the work and then present a working system to 
the community for comment and review. I still intend to do that, but 
given some recent discussions, I think the time is right to bring this 
up and see where it goes.

(Sorry for the cross posting, but since it involves both projects, I 
wanted to make sure all saw it - if possible, please reply on lfs-dev.)

Proposal:

1. Adjust LFS/BLFS to auto-generate build recipes for individual 
packages that a packaging tool can use to create binary packages with 
meta information included such as dependency tracking.

2. Store 'official' copies of those binary packages in a developer 
package repository so that when developing (primarily BLFS) a dev can 
automatically pull and install into a build environment the dependencies 
he needs to build and create an individual package.

3. Create a standard workflow and tools whereby a developer can 
accomplish #2 and edit the book accordingly in an efficient, reliable way.

Rationale:

(B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a 
huge undertaking - and it's a difficult beast to maintain. In order to 
create a stable reference page in BLFS an editor has to have spent the 
time to build all of LFS, tweak it, go through current BLFS, manually 
install dependency packages and then carefully document the package he 
builds. No two developers are guaranteed to have the same environment, 
either, so accuracy and stability becomes an issue.

The same is true of the LiveCD project, and is the main reason why it 
sits dead today. It is difficult to maintain when there are no packaged 
binaries to draw from and the entire thing is a scripted source build.

Let me just say now that because (B)LFS is primarily (and probably 
should always be) about educating, I don't think we should require 
end-users to use package management. Mainly the proposal is intended to 
assist in development. However, if we have taken the time to incorporate 
PM in our dev workflow, we can make the option of building via PM tools 
available to readers if they wish to use it for themselves and build 
their own package repository.

Details:

(The following details assume pacman is the package manager chosen, but 
it could conceivably be another, such as rpm5.)

1. The end of LFS chapter 5 is modified to (optionally) build the 
packaging tool and any dependencies it has.

2. LFS chapter 6 is modified so that for each package a build recipe 
(e.g. PKGBUILD file) is generated from the book's source. A reader is 
given the option of carrying out the build manually or via the packaging 
tool.

3. LFS devs create official copies of the binary packages and install 
them to a semi-public package repository

4. BLFS is modified to also generate build recipes (PKGBUILD files) from 
its source

5. As BLFS devs work on individual packages, they can use the defined 
workflow and tools to generate a chroot environment with only the 
packages they need for build-time dependencies - they can then both 
produce a binary version of the package as well as document what they've 
done, the end product being a BLFS page which will generate/correspond 
to the PKGBUILD file.

6. BLFS dev updates the BLFS binary package repository with the 
'official' package and other devs can now draw from and use those when 
working on their respective package.

There are, I'm sure, both positives and negatives to this proposal, and 
I'd like to hear everyone's thoughts.

I intended to do all the development in the jh branch, but if there are 
more parties interested in helping this development, then I'm also open 
to sharing the workload and perhaps creating an environment where this 
can be done together.

JH

problem of bootscript setclock

xinglp — 2012-05-12T18:27:16

Now, It is the job of udev to start /etc/init.d/setclock .

When I use initd-tools to install somethings else, it was installed
for depended.

And I THINK , ntpd and checkfs should not depend on $time.

resizecons : a proposal

Ken Moffat — 2012-05-11T15:06:54

 First, some assertions:

1. resizecons cannot work without video mode files, which are
produced by a program from the svgalib package.

2. svgalib is defunct, and was only applicable to linux kernels
before 2.6 : there are patches around to enable it to be compiled,
and some distros include it, but it seems very much a minority
interest.

3. the console will be resized to suit the font when 'setfont' is
run.

4. if the resulting font appears too tiny, you can pass video=
arguments to grub, e.g. I use video="1024x768" on one of my machines
which uses kms and a small (8x16) font.  Known to work on
framebuffers, including kms - I haven't built a non-framebuffer
kernel in years.

 The proposal:

 If the first 3 assertions are correct, then I suggest that we should
remove resizecons, and its manpage, from the build - with some seds
(not yet tested), and in explaining the seds use a short summary of
assertions 1-3, or even of 1-4.

 Comments ?

ĸen

resizecons not installed by kbd

xinglp — 2012-05-10T20:06:55

As described at
http://www.linuxfromscratch.org/lfs/view/development/chapter06/kbd.html

But the manpage of resizecons was installed.

Suggestion

Jeremy Huntwork — 2012-05-09T20:19:27

Greetings all,

Consider two things:

1. We all hate long build times. Anything we can (reasonably and 
accurately do) to speed up the build we do.
2. Chapter 5 are a set of throwaway tools (in some cases we only build 
just what we want out of those tools, again, for sake of speed, i.e., 
gettext)

Given the above, why don't we use busybox in chapter 5? If we 
standardize a config we could get rid of 12 packages in chapter 5, 
namely: ncurses, bash, bzip2, coreutils, diffutils, findutils, gawk, 
grep, gzip, sed, tar, xz. Possibly 13, patch, although the last time I 
tested busybox's patch it didn't quite work as hoped, but it's possible 
it is fixed now.

In addition to being able to drop those packages, you also get free of 
charge a vi editor and wget utility for use in chroot.

Thoughts? If interested, I could start a mockup in the jh branch.

JH

gtk-doc-rebuild.xml

Ken Moffat — 2012-05-07T17:55:26

 In gegl, Fernando noted that the shipped documentation is installed
if gtk-doc being present, but the explanation says:

--enable-gtk-doc: Use this parameter if GTK-Doc is installed and you
wish to rebuild and install the API documentation.

 Unfortunately, this is the standard xinclude.  For gegl it would
make more sense to say "Use this parameter if GTK-Doc is installed
and you wish to rebuild the shipped API documentation."

 BUT - is such a change always appropriate, or are there perhaps
some strange gtk packages which ship documentation but don't install
it ?

ĸen

Wording fix

Jeremy Huntwork — 2012-05-05T14:24:25

Looks like I missed some necessary text changes. At the bottom of
chapter 5 glibc, in the sanity check box, the following sentences are
no longer accurate and can be removed:

"Something may have gone wrong with the specs file amendment above. In
this case, redo the specs file amendment, being careful to
copy-and-paste the commands."

Thanks,

JH

Rename sources?

Andrew Benton — 2012-05-04T10:45:35

Hello All,

There's a rather ill natured thread on LFS Support at the moment called
Chapter 5 questions. Scott Robertson has made an interesting point:

On Fri, 04 May 2012 11:35:32 +0100
Scott Robertson <scottrobertson33< at >yahoo.com> wrote:


I think it's a good point and it would help some people who are new to
the book if we renamed the sources folder "materials" or "resources" or
"packages" or something.

Andy

/etc/rc.d/init.d/sysctl 's "Required-Start" should bemountvirtfs

xinglp — 2012-05-02T07:20:16

The "mountkernfs" has been renamed to "mountvirtfs".

Broken sound (glibc).

Ken Moffat — 2012-05-01T19:05:46

 My shiny new LFS system is heading for /dev/null.  That's ok, it
was only a test of current packages, but I must admit I'd hoped to
keep it for a week or two.

 The reason is that although I've built everything except for some
gnome packages, I didn't test sound until last night.  Totally
broken.  gvolwheel reported it couldn't connect open the mixer,
although alsamixer runs ok.  aplay segfaults, but the segfault is in
ld-2.15.so.

 Google found that *some* people have been hitting this since
glibc-2.14.  It also pointed me to a patch at cross-lfs,
http://patches.cross-lfs.org/dev/eglibc-2.15-fixes-1.patch
which is from the libc-alpha list last year.  It applies (eglibc
isn't _that+ different :), but I'm reluctant to try upgrading the
running glibc - doing in-place toolchain updates is the beginning
of a slippery slope!

 I'll try a fresh test build, and this time test 'aplay' in chroot.
So, for the moment this is just a heads-up that I'm looking at this.

 Still puzzled about what suddenly broke this for me, LFS-7.1 on
this machine was fine but the problem first surfaced (for some
people) last summer.

ĸen

New failure in coreutils tests

Ken Moffat — 2012-04-28T23:39:07

 (resending, hopefully I've got the right list this time)

 I'm building the current book with the newer grep, man-pages,
kernel-headers, and autofoo that Matt is working on.  This is as a
test of my hardware (looking good at the moment, but a few BLFS
packages have caused me ICEs recently, so not yet certain if it is
now ok - will reply to the earlier thread with the gory details when
I'm convinced :)

 The host system is LFS-7.1.  In coreutils it now fails in 'check
user' with
../build-aux/test-driver: line 95: 12348 Aborted "$< at >" > $log_file
2>&1
FAIL: test-getlogin

 which sets non-zero status and breaks my build at the end of 'check
user'.  The code is

# Test script is run here.
"$< at >" >$log_file 2>&1
estatus=$?
if test $enable_hard_errors = no && test $estatus -eq 99; then
  estatus=1
fi

 I'm assuming this is from gnulib-tests/test-getlogin.c.  Not seen
this failure in my builds earlier this week, perhaps it's a one-off
or perhaps something in the 3.3.4 headers has changed.

 Or, maybe it's just my hardware (again).

ĸen

Nitpick on the jh merge

Ken Moffat — 2012-04-26T18:02:57

 Working my way through the changes to my own scripts, when I got to
chapter 6 I found 6.10 was still called Re-adjusting the Toolchain,
despite the apparent rename of the xml file, and I found the first
part of the text confusing in the light of the chapter 5 changes.

 Compare
http://www.linuxfromscratch.org/lfs/view/development/chapter06/readjusting.html
 to
http://www.linuxfromscratch.org/lfs/view/jh/chapter06/adjusting.html

 I think that it's just the text in the first para after 'it is time
to adjust the toolchain' which has old content, but the name of the
html should probably also be changed to 'adjusting.html'.

 I can have a go at fixing this, but I'd like someone to confirm
it's wrong (wouldn't be the first time I've misread things).

ĸen

The jh branch has been merged

Bruce Dubbs — 2012-04-25T19:34:22

I've just merged the jh branch into trunk.  I had a little problem with the svn 
merge command so I baically did it manually.

Please pay close attention to any new builds and give tell us any issues you see 
with instructions, text, or the xml.

I have also updated the web site version of the book so there is no need to wait 
for the nightly build.

   -- Bruce

glibc configparms: any experience with -O3 on x86_64 ?

Ken Moffat — 2012-04-24T19:43:43

 For i?86, when we force it to build for m486 we also add -O3.  I've
been using -O3 for glibc on x86_64 in case it turns out to be
beneficial.  On my old single processor machines, I doubt that it
helped, but my suspicions about it are actually raised by results on
my phonon which definitely has enough horsepower.

 On LFS-7.1 I noted ldd segfaulted for one of the gst plugins
packages near the end of my system build, but that eventually built
ok.  On my i3, no problems.

 Now I'm doing my first test build of current svn, mainly to iron
out the bugs in my scripts, and then to sort out the changes for the
first part of my desktop scripts.  Here, glibc bombs out very
quickly (internal compiler error, segmentation fault in vfscanf.c)
.
 Did it twice, so at that point I dropped back to -O2 and it was ok.
Perhaps I should mention that everything else using my own CFLAGS
uses -O2, it's only glibc where I've tried -O3.

 Has anyone seen similar problems with -O3 in glibc (or, converesely,
has anyone used -O3 without any problems) ?  I can see that I'll have
to have a go at recompiling glibc when the LFS packages have finished,
and then (if it still crashes), have to work out how to get the
preprocessed source.  I'm hoping its just a problem with the
temporary version of gcc in /tools.

 I'm just glad I'm not doing this on a slow i686 box :)

ĸen

Cherry picking r9818 and r9822 for trunk

Matt Burgess — 2012-04-23T20:33:25

Hi,

I don't think $subject should be particularly contentious, but thought
I'd send a request for approval/comments just in case.

So, ticket #3066 states that on certain hosts Ncurses fails to build if
GPM is installed.

This is because the configure script is apparently finding the GPM
headers on the host.  This is Not Good (TM).

The fix for this is to add
--with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
builds so that it doesn't look at /usr/include at all.

In addition, --without-cloog and --without-ppl can be removed as they
don't do anything useful.

Jeremy, my gut feeling is that your proposed build method changes may
well make it into trunk fairly shortly, but in the mean time I'd like to
take the above mentioned commits as they fix known issues and are as
applicable to the old build method as the new (i.e. they don't require
any of your other changes in order to be applied to trunk).

Any objections?

Ta,

Matt.

Minor nitpick

Jeremy Huntwork — 2012-04-23T16:45:46

This changelog entry on 2012-04-05 isn't quite correct. It reads:

[matthew] - Use su from chapter 6 Coreutils in the Bash instructions, 
instead of the one from chapter 5. Install su as su rather than su-tools 
in chapter 5. Fixes #3057.

coreutils in chapter 6 doesn't install su. So the su you're using for 
tests all throughout chapter 6 is the one we explicitly install from 
chapter 5 coreutils. su is installed in chapter 6 by the shadow package.

I can't recall offhand why we chose to use su-tools originally. Probably 
just as a nominal reminder that we were using the one in /tools. :)

If I get a chance, just for curiosity, I'll see if I can look up that 
thread.

JH

Summary of changes in JH toolchain proposal

Bruce Dubbs — 2012-04-23T03:36:37

I've been studying Jeremy's changes and want to summarize them here.

Chapter 5
   Binutil pass 1
     Add two configure options:
       --with-sysroot=$LFS
       --with-lib-path=/tools/lib

     These are not in the main binutils configure command, but are in the
     configure for ld


   gcc-pass1
     Change 28 header files (as in pass2):
       3 sparc, 1 mn10300, 1 tilepro, 1 alpha, 1 vax, 2 ia64, 2 mips,
       1 bfin, 1 cris, 1 microblaze, 1 s390, 1 xtensa, 1 m68k, 3 i386,
       1 sh, 1 m32t, 3 rs6000, 1 tilegx, 1 frv, and 1 base linux.h

       The only places that affect us where the sed matches is in
       gcc/config/i386/linux.h and gcc/config/i386/linux64.h.
       I doubt any of the other files need to be
       changed, but it doesn't hurt anything either.

     for file in \
       $(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
     do
       cp -uv $file{,.orig}
       sed -r -e 's< at >/lib(64)?(32)?/ld< at >/tools&amp;< at >g' \
              -e 's< at >/usr< at >/tools< at >g' $file.orig &gt; $file
       echo '
#undef STANDARD_STARTFILE_PREFIX_1
#undef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' >>  $file
       touch $file.orig
     done

      Add five configure options
        --with-sysroot=$LFS        \
        --with-newlib              \
        --without-headers          \
        --with-local-prefix=/tools \
        --with-native-system-header-dir=/tools/include \

      Remove two configure options
        --without-ppl
        --without-cloog

   Adjusting the toolchain
      Remove completely

   binutils-pass2
      Remove -B/tools/lib/ from CC

   gcc-pass2
     Remove startfiles_fix-1.patch

     Add code:
     cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \
     `dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/include-fixed/limits.h

     Remove code:
       case $(uname -m) in
        x86_64)
          for file in $(find gcc/config -name t-linux64) ; do \
           cp -v $file{,.orig}
           sed '/MULTILIB_OSDIRNAMES/d' $file.orig > $file
          done
       ;;
       esac

       Configure:
        Remove -B/tools/lib/ from CC
        Remove configure options
         --with-native-system-header-dir=/tools/include
         --without-ppl
         --without-cloog

Chapter 6

No significant changes.  Rename 'Re-adjusting the Toolchain' section to 
'Adjusting the Toolchain'

   -- Bruce

minor

Jeremy Huntwork — 2012-04-22T22:41:36