Anyone went through dependacies for coreutils???

Richard Lightman richard at nezumi.plus.com
Fri Apr 4 11:51:54 PST 2003


* DJ Lucas <dj_me at swbell.net> [2003-04-04 19:35]:
> Anyone using coreutils yet?
> 
Yes, but I have not tried it yet.

> Reason why I'm asking is specifically for build order...
> 
> From the cvs book...
> ....
> Installing Textutils-2.1
> Installing Sed-4.0.5
> Installing Flex-2.5.4a
> Installing Binutils-2.13.2
> Installing Fileutils-4.1
> Installing Sh-utils-2.0
> ....
> 
> Textutils is built before Sed, Flex, and Binutils, then Fileutils and
> Sh-utils.  I was wondering if anyone knows why that specific build
> order.

You can find many of the reasons in the "Keeping chapter 5 and chapter
6 separate" hint.

>  Flex is not built in Chapter 5, sed and binutils are. 

The host system's flex static library is linked to anything in
chapter 5 that requires it.


> Flex is
> not listed as a dependacy for building Fileutils or Sh-utils, but do
> these packages place any hard coded references to executables or libs
> that are part of binutils or sed?

My build scripts are designed for parallel builds, and so far have
proved reliable. They use a symlink forest to prevent any possible
problems with /static/* being hard coded. They have only glibc
as a dependency for textutils sed binutils fileutils and sh-utils.

My scripts need some extra stuff to enter chroot, and anything
that can be delayed until after entering chroot (like flex) is delayed
because it is simpler to code and test that way. After glibc, my
scripts would build packages in this order (up to flex), in part
because of the dependencies (given after the '-'), but mostly because
that is the order make chose for them:

: bzip2 - create_passwd glibc
: m4 - create_passwd glibc
: bison - create_passwd glibc m4
: tar - create_passwd glibc
: gcc - create_passwd glibc tar
: groff - create_passwd glibc bison gcc
: ncurses - create_passwd glibc gcc
: less - create_passwd glibc ncurses
: gettext - create_passwd glibc
: net-tools - create_passwd glibc gettext
: perl - create_passwd glibc bison gcc groff less net-tools
: help2man - create_passwd glibc perl
: chrude - create_passwd glibc help2man
: findutils - create_passwd glibc
: ed - create_passwd glibc
: patch - create_passwd glibc ed
: zlib - create_passwd glibc
: flex - chroot bison



> Currently, I've set instructions up
> to build coreutils twice just to CMA, but I'm thinking it's not
> necessary.  Has anyone been through this and verified?  If not, how
> would one go about checking this? 

* Read any README files in the source for coreutils.
* Read the output configure.
* If you do not use the symlink forest trick, look for the /static in
  every file in $LFS, after removing $LFS/static.
* I just checked ldd output for /{,usr/}{,s}bin/*, and did not find
  libfl. This is something I should investigate. It could be caused
  by my scripts not working the same way as LFS.


> I was thinking of a list of files
> (taken from the Textutils and Sh-utils lists) and greping both ldd's
> output, and the files themselves, for the binaries and libs that are
> part of binutils

Probably easier to just look for /static in everything. Safer too,
as you might find something we missed.


> (what are the lib files, is there already a list
> availible?) , and also for sed. 

See attachment. It was created using DESTDIR (or whatever the package
uses for that purpose).


> Assuming there are no references with
> the old static paths, place the coreutils install in place of textutils,
> and then smoke the sh-utils and fileutils sections.  Is this the
> proper/sufficient test case? 
> Doing too much work? 
> Not enough?
> 

Judging from the purpose of each package, you are probably doing too
much work, but better safe than sorry.

Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: file_lists.tar.bz2
Type: application/octet-stream
Size: 994 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20030404/8105e372/attachment.obj>


More information about the lfs-dev mailing list