Pure LFS / Next LFS Release

Jouko Orava joorava at pcu.helsinki.fi
Wed May 28 05:28:04 PDT 2003


On Wed, 28 May 2003, Ian Molton wrote:
> I think its silly.   theres no need to make it special and it
> complicates the book.
>
> Gerard! put your foot down please, this ones driving us nuts...

I'd like to advocate using a variable for /stage1 because the
side effects are something of value for me.

There are two totally different types of patches needed to build LFS cvs.
Normal ones are not really LFS-specific, but fix or modify the behaviour
of a package; for example, gcc no_fixincludes and mmap patches.
The other ones only modify hardcoded paths or other configuration to
work with a specific LFS setup; for example, gcc specs patch.
This latter type really irritates me.

If you have chosen anything else than /stage1, or if you have the name
in a variable, you *cannot* use configuration patches.
I would like to get rid of the configuration patches, as they are
confusing and break way too often.

Below, I'll explain some of the side effects in more detail, but in
short, they are very beneficial to me, and might be useful enough
to be considered in the book even if /stage1 stays.

However, I fully agree that it is time for Gerard to put his foot down;
this is the way I'd like LFS to go, but it is for Gerard to decide.
The results may change the book (in spirit, if not much in writing),
so I wish Gerard made his decision soon..

Cheers,
  Jouko Orava

Below, there are the side effects of letting users choose "/stage1"
for themselves (by storing it in a variable), and some of my findings
of converting configuration patches to bash script functions (as
config patches cannot be used when /stage1 is not fixed).

Sorry for the very long message.



In Chapter 5 of LFS cvs, there are three packages that need configuration
or path modification: binutils, gcc, and perl. For perl, hints/linux.sh
is modified twice: first with the -libc patch, then with an addition
to the end of the file. Silly, eh?

However, *all* of these are simple replacements (and additions to the end
of the file), easily done with mv, sed and printf.
I prefer printf over echo, because printf has consistent escape handling,
and many echo implementations do not.

Aside from getting rid of the (to me) irksome config patches, it
would be much better to use bash scripts (or functions):

 * People writing their own build scripts could incorporate them
   very easily (well, as is) to their own scripts.

 * People building LFS would understand the difference between
   "patching source code", and "modifying package configuration
   so that we get a reliable toolchain for LFS".
   The modifications for different packages is also similar enough
   to give a good idea how to do such a modification to a new package.

 * Patches are very likely to break often - see GCC specs patch.
   Scripts, if done correctly, work across a large range of versions.
   For really radical changes, the previous point applies.

To minimise typing errors, and ensure "correct" handling of the source
files, I propose using a bash script (function) for all of these
modifications. Basically, something like this (filename in FN):

  if [ -f "$FN.orig-lfs" ]; then
    rm -f "$FN"
  else
    mv "$FN" "$FN.orig-lfs"
  fi
  sed [..something..] < "$FN.orig-lfs" > "$FN"
  # printf [..something..] >> "$FN"

Preferably declared in a bash function, and used thorough the function;
not re-typed again and again. There are important reasons why the
script should be close to the above:

  * The original file contents and *timestamp* are kept unmodified.
    Paranoid people like me like to have unmodified files keep their
    original timestamps.

  * Multiple reruns of the above script provide consistent results.
    Original is kept unmodified, and you get only the latest changes.
    Nothing of previous modifications are kept.
    The first five lines, and they only, are critical.

  * It is very simple to find out what exactly was modified:
      diff -Naur "$FN.orig-lfs" "$FN"

  * You can locate modified files by searching for the ".orig-lfs"
    suffix.

For gcc, I use a for-loop (gcc/config/*/*.h) and check whether
the file contains "suspect strings" before modification,
and list each modified file name in the build script.

I'd be more than happy to provide the needed shell script functions
for Chapter 5; I didn't dare to include them, as the general atmosphere
seemed hostile to this approach.. Any takers?
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list