🚀 go-pugleaf

HateLinux wrote:
> 
>         Could someone please help me compile a static gcc, for a linux
> from scratch system I'm building. 
[.......]

If you must use 2.95.3 have a look at LFS *cvs* version (comes with free patch!)
http://linuxfromscratch.org/index.shtml (pick a mirror). If you search the
mailing lists there, you will find a vast amount of information on compiling
gcc. BTW, GNU info for gcc is extensive & somewhat helpful, if you get pinfo
from /contrib on your favorite Slackware mirror, it's easy to read too. 

-WBD

On Wed, 22 Aug 2001, HateLinux spake:
> 	Could someone please help me compile a static gcc, for a linux

You want GCC itself to be statically linked? Really?

(Strange, but doable.)

> from scratch system I'm building. I have the full source to gcc
> v2.95.3 and 3.0 , the latest gnu-make, am following instructions and
> what little intelligible docs there are, but only come up with dozens
> of errors.

There are a big bunch of docs, actually. The big hole is for
cross-compiler docs. I've been meaning to write some for *ages*... but I
can never find the time :(

> 	The more I hack, the worse the errors become. I don't really
> want to print hundreds of lines of debugging info here on the
> newsgroup. Someone compile it and tell me how , so I can see where I
> went wrong , or at least get the same errors (make me feel better).

The rough procedure is (assuming that this isn't a cross-compiler):

- optionally install DejaGnu-1.4 (if your distributor has packaged it)
  or sources.redhat.com:/pub/gcc/infrastructure/dejagnu-20010126.tar.gz
  otherwise; this is needed to run the test suite (which, for GCC-2.95.x,
  is only available in the GCC CVS tree; I recommend getting and running
  it anyway; it's a useful way of telling if your GCC is rather broken.
  A few dozen tests are likely to fail, but if hundreds or thousands do
  then you can start getting suspicious.)

- Make a separate build directory, *not underneath the source tree*.
  So if your source tree is /usr/local/src/gcc-2.95.3, make, say,
  /usr/local/src/build-gcc, and cd into it.

- Run configure from that directory. You probably want to provide
  --enable-static --disable-shared; you may also want to specify
  --enable-languages=c,c++,f77 to disable the rarely-used CHILL
  compiler and the prototype (in GCC-2.95.x) Java compiler.

- Run `make bootstrap', and wait. The system will build a support
  library, then texinfo (to make the info pages), then the compiler,
  then it'll recompile itself with the latest-built compiler twice
  and compare them; finally it'll build the runtime libraries and
  C++ standard library. This could take from five minutes (on a
  *really* high-end system) to fifty hours (on a 386 with 6--8Mb
  of RAM).

  (If the comparison fails, it is a *serious* error; if it fails
  on a major platform, it probably means your platform is faulty or
  you're doing something that doesn't work yet like trying to build
  GCC on an ultrasparc in 64-bit mode.)

  If the compiler ICEs or crashes in the middle of the build, it's
  also likely a hardware failure. The only GCC that is incapable of
  building GCC-2.95.3 to my knowledge is GCC-2.0 itself, which
  unless you are a dedicated antiquarian you won't be running.

- Run `make -k check' (if you want to run the testsuite, have the
  testsuite, and have DejaGnu installed).

- If you're satisfied with the test results, `make install'.

That's it.


There are some extra complexities if you're building a system from
scratch. If you're doing that, you may well not have a C library yet for
the target system. In that case, the procedure given above will fail,
because GCC's compiler-support library makes calls to the C library;
you'll probably get messages about fprintf() and friends not existing
towards the end of the first stage of the compiler bootstrap. You can
build a barely-functional compiler by running `configure' as normal and
then putting at the top of gcc/tconfig.h the text

#define inhibit_libc 1

and building. This compiler should probably be built with
--enable-languages=c, and should probably only be used to build the C
library, because it will be essentially incapable of exception handling
and a good few other things. Once you have a C library, you should
rebuild the compiler in a more conventional fashion, and it should work.


Also, if you're building a from-scratch system, take note of the release
notes for glibc-2.2.4; they apply to glibc-2.2.3 as well. Namely,
several patches to GCC-2.95.3 are required, or GCC-2.95.4pre from the
head of the gcc-2_95-branch in GCC CVS with one patch (the patch given
at the URL in the 2.2.4 release notes). The symptoms if you don't build
this patch are that this program fails to link, with an error about
atexit being undefined, even though `nm -D' shows atexit plainly visible
in /lib/libc.so.6:

int atexit (void (*)(void));
int main (void)
 {
  atexit (main)
  return 0;
 }

Also, you may need a recent binutils, perhaps a very recent
one. (Getting a very recent binutils is recommended anyway because a
bunch of i386 assembler and linker bugs have just been stamped out.)

> 	I installed zipslack v 8.0  just for this purpose. (to make a
> LFS system). I can delete it and start from scratch in ten minutes or
> so if I really fsck up the system, leaving my main linux intact.

There's no need for that; just configure your test GCC with a different
--prefix or --program-prefix (so it doesn't collide with the
already-installed GCC) and see if it works. If it works, rebuild it with
the right --prefix.

GCC and binutils are core tools, but unlike glibc or the kernel if you
bugger them up the worst that can happen is you can't compile
anything... that's far more easily recoverable-from than a machine with
a toasted glibc or kernel.

> "The GNU project regards man pages as obsolete and should not let them
> take time away from other things." (man gcc).

This is no longer correct; bear in mind that GCC-2.95.x is quite old.
The GCC project now uses texi2pod to transform the `Invoking GCC'
section of the Info documentation into POD format, and then uses
`pod2man' to transform *that* into man form. (There's also a GNU
help2man tool that we could use; I'm not sure why we use texi2pod and
pod2man instead; perhaps because the pod2man author reads the GCC
mailing list ;) )

> "zipslack does not consider 'info' as essential " (/me).

I hate to say it, but the GNU Project's policy is right here, just badly
stated. What is really obsolete is *writing* man pages. The point about
texinfo documentation is that it is a *logical* markup system, like a
cross between HTML and DocBook. As such, it can be converted both into
other logical markup systems (HTML, DocBook, POD) and physical markup
systems (PDF, TeX, nroff/man) quite easily.

Try converting a man page of comparable complexity to the `Invoking GCC'
section of the GCC manual into anything other than physical markup
sanely. (You'll fail.)

The problem with texinfo was that for a long time the only converter
that anyone used was makeinfo, which threw nearly all the presentational
info away, and the only readers people used were info and Emacs Info,
both of which are quite sparse and the first of which was for a long
time almost totally unusable. Because there wasn't a path of converters
from texinfo to man, man pages had to be separately maintained, which
meant that they fell into disrepair.

Things are much better now; you can view texinfo documents in myriads of
viewers, from pinfo through TkMan through dwww and other web viewers,
and you can convert it into just about any imaginable format.

Texinfo was ahead of its time ;)

-- 
`It's all about bossing computers around. Users have to say "please".
Programmers get to say "do what I want NOW or the hard disk gets it".'
                        -- Richard Heathfield on the nature of programming

Nix wrote:
> 
> On Wed, 22 Aug 2001, HateLinux spake:
> >       Could someone please help me compile a static gcc, for a linux
> 
> You want GCC itself to be statically linked? Really?
> 
> (Strange, but doable.)
[...........]

Mr HateLinux is doing LFS ( http://linuxfromscratch.org )(TFM for static GCC:
http://www.linuxfromscratch.org/view/3.0-pre4/ch05-gcc.html ). Needs to be
static at that stage, no libs to link to.

-WBD

	Thank you all for your help. 
	Linux from scratch docs can be DL here:

ftp://ftp.linuxfromscratch.org/lfs-book/3.0-pre4/LFS-BOOK-3.0-pre4-NOCHUNKS.html.bz2

It is just a 70k DL , and worth the effort. 
	Nix's reply has been printed , I will carry it around with me
until I can understand it fully.
	I downloaded the (cough) close to 50 Mb of text Warren
suggested , and will grep and grope through it until I understand
more.
	And as he and Geoffrey pointed out , the idea of linux from
scratch is to make the very basic stuff, statically linked , then you
can then carry that stuff around on a CDRom, and use it to build your
own system , tailored to your CPU/ hardware/whims. You learn much more
about the basic structure of linux, and rely less on distributions (is
Redhat really joint owned by microsoft ??? Maybe that's why they
included GCC 2.96 in version 7.0 ;)     )
	FWIW



>	Could someone please help me compile a static gcc, for a linux
>from scratch system I'm building. I have the full source to gcc
>v2.95.3 and 3.0 , the latest gnu-make, am following instructions and
>what little intelligible docs there are, but only come up with dozens
>of errors.
>	The more I hack, the worse the errors become. I don't really
>want to print hundreds of lines of debugging info here on the
>newsgroup. Someone compile it and tell me how , so I can see where I
>went wrong , or at least get the same errors (make me feel better).
>	I installed zipslack v 8.0  just for this purpose. (to make a
>LFS system). I can delete it and start from scratch in ten minutes or
>so if I really fsck up the system, leaving my main linux intact.
>	TIA
>
>"The GNU project regards man pages as obsolete and should not let them
>take time away from other things." (man gcc).
>
>"zipslack does not consider 'info' as essential " (/me).
>
>;)

On 23 Aug 2001 00:04:12 +0100, Nix <$}xinix{$@esperi.demon.co.uk>
wrote:
>The rough procedure is (assuming that this isn't a cross-compiler):
>
>- optionally install DejaGnu-1.4 (if your distributor has packaged it)
>  or sources.redhat.com:/pub/gcc/infrastructure/dejagnu-20010126.tar.gz
>  otherwise; this is needed to run the test suite (which, for GCC-2.95.x,
>  is only available in the GCC CVS tree; I recommend getting and running
>  it anyway; it's a useful way of telling if your GCC is rather broken.
>  A few dozen tests are likely to fail, but if hundreds or thousands do
>  then you can start getting suspicious.)
>
>- Make a separate build directory, *not underneath the source tree*.
>  So if your source tree is /usr/local/src/gcc-2.95.3, make, say,
>  /usr/local/src/build-gcc, and cd into it.
	OK
mkdir /usr/src/build
cd /usr/src/build
>
>- Run configure from that directory. You probably want to provide
>  --enable-static --disable-shared; you may also want to specify
>  --enable-languages=c,c++,f77 to disable the rarely-used CHILL
>  compiler and the prototype (in GCC-2.95.x) Java compiler.
/usr/src/gcc-3.0/configure  --enable-static --disable-shared
--enable-languages=c,c++,f77
make bootstrap
	OK
>
>- Run `make bootstrap', and wait. The system will build a support
>  library, then texinfo (to make the info pages), then the compiler,
>  then it'll recompile itself with the latest-built compiler twice
>  and compare them; finally it'll build the runtime libraries and
>  C++ standard library. This could take from five minutes (on a
>  *really* high-end system) to fifty hours (on a 386 with 6--8Mb
>  of RAM).
	Took 10 seconds...

if [ x"" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g -O2 -I.
-I/usr/src/gcc-3.0/libiberty/../include  -W
-Wall -Wtraditional -pedantic  /usr/src/gcc-3.0/libiberty/fnmatch.c -o
pic/fnmatch.o; \
else true; fi
gcc -c -DHAVE_CONFIG_H -g -O2 -I.
-I/usr/src/gcc-3.0/libiberty/../include  -W -Wall -Wtraditional
-pedantic /usr/src/gcc-3.0/libiberty/fnmatch.c
In file included from /usr/include/errno.h:36,
                 from /usr/src/gcc-3.0/libiberty/fnmatch.c:46:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
make[1]: *** [fnmatch.o] Error 1
make[1]: Leaving directory `/usr/src/build/libiberty'
make: *** [all-libiberty] Error 2/usr/include/bits/confname.h:565:
warning: comma at end of enumerator list
In file included from /usr/src/gcc-3.0/gcc/toplev.c:35:
/usr/include/sys/resource.h:52: conflicting types for `getrlimit'
/usr/src/gcc-3.0/gcc/system.h:330: previous declaration of `getrlimit'
/usr/include/sys/resource.h:72: conflicting types for `setrlimit'
/usr/src/gcc-3.0/gcc/system.h:341: previous declaration of `setrlimit'
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x0809b9d0 PID 9850
make[2]: *** [toplev.o] Error 1
Removing child 0x0809b9d0 PID 9850  from chain.
make[2]: Leaving directory `/usr/src/build/gcc'
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x080cd8c0 PID 9462
make[1]: *** [stage1_build] Error 2
Removing child 0x080cd8c0 PID 9462  from chain.
make[1]: Leaving directory `/usr/src/build/gcc'
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x0809f1d0 PID 9412
make: *** [bootstrap] Error 2
Removing child 0x0809f1d0 PID 9412  from chain.
root@darkstar:/usr/src/build#



So I corrected a couple of links to the kernel source (asm and linux
links). I did not find any references to these links in the gcc docs ,
but lfs docs had them. Now it compiles for about four minutes and
crashes at this :
             Finished prerequisites of target file `cc1'.
            Must remake target `cc1'.
gcc  -DIN_GCC    -g  -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
-DHAVE_CONFIG_H  -o cc1 \
        c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o
c-semantics.o c-dump.o libcpp.a  toplev.o libbackend.a obstack.o
./intl/libintl.a      ../libiberty/libiberty.a
Child access: user 0 (real 0), group 0 (real 0)
gcc: ../libiberty/libiberty.a: No such file or directory
Got a SIGCHLD; 2 unreaped children.
Putting child 0x08177488 (cc1) PID 3751 on the chain.
Live child 0x08177488 (cc1) PID 3751
Reaping losing child 0x08177488 PID 3751
make[1]: *** [cc1] Error 1
Removing child 0x08177488 PID 3751  from chain.
make[1]: Leaving directory `/usr/src/build'
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x080eaac0 PID 2876
make: *** [stage1_build] Error 2
Removing child 0x080eaac0 PID 2876  from chain.
root@darkstar:/usr/src/build#

Which is exactly the error I had under redhat and gcc-2.96.
I'm tired. Just spent 4 hours on this and no where closer to compiling
gcc than I was two weeks ago.. I also grepped through the 100
megabytes of letters in the lfs mailing lists , but there was no help
there. Night all..

HateLinux wrote:
[.......]
> 
> Which is exactly the error I had under redhat and gcc-2.96.
> I'm tired. Just spent 4 hours on this and no where closer to compiling
> gcc than I was two weeks ago.. I also grepped through the 100
> megabytes of letters in the lfs mailing lists , but there was no help
> there. Night all..

Have you tried doing the *book* version of LFS yet?

Packages here:
http://linuxfromscratch.org/download/packages.shtml

books here:
ftp://ftp.linuxfromscratch.org/lfs-book/3.0-pre4/

Has been heavily tested & is known to work :)

The LFS mailing lists are helpful, so is the IRC channel, but if your question has already been answered, you might just get told to search the mailing list.

-- 
There is no answer. There is no question. There is only the road, which stretches out in front of you, an endless night of coffee, technical manuals, snack food wrappers, disgruntled family members, and hundreds of hours spent struggling to become adept. Or you can hire a consultant. -Tom Oehser.

On Thu, 23 Aug 2001, Warren Doney stipulated:
> Mr HateLinux is doing LFS ( http://linuxfromscratch.org )(TFM for static GCC:
> http://www.linuxfromscratch.org/view/3.0-pre4/ch05-gcc.html ). Needs to be
> static at that stage, no libs to link to.

If there are no libs to link to, what is GCC being linked to in order to
build anything?


(Admittedly the way around that is rather longwinded, involving a
cross-compiler build and a build of glibc with that corss-compiler;
maybe this is OTT... ;) )

-- 
`It's all about bossing computers around. Users have to say "please".
Programmers get to say "do what I want NOW or the hard disk gets it".'
                        -- Richard Heathfield on the nature of programming

On Sat, 25 Aug 2001, HateLinux said:
> So I corrected a couple of links to the kernel source (asm and linux
> links). I did not find any references to these links in the gcc docs ,

It wouldn't have them; GCC is not Linux-specific, and the necessity for
those links comes from glibc, not GCC. The glibc FAQ mentions the links.

>              Finished prerequisites of target file `cc1'.
>             Must remake target `cc1'.
> gcc  -DIN_GCC    -g  -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
> -DHAVE_CONFIG_H  -o cc1 \
>         c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o
> c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o
> c-semantics.o c-dump.o libcpp.a  toplev.o libbackend.a obstack.o
> ./intl/libintl.a      ../libiberty/libiberty.a
> Child access: user 0 (real 0), group 0 (real 0)
> gcc: ../libiberty/libiberty.a: No such file or directory

You've got a broken make, I guess, or a missing `ar'. libiberty is built
as the first stage of the bootstrap, in /usr/local.

If a build fails because of system-wide problems like missing include
files or includes pointing in the wrong place, zapping the build
directory and restarting from `configure' is wise; you'll probably find
it works then. (Maybe.)

> Which is exactly the error I had under redhat and gcc-2.96.

Strange error. What's in the libiberty/ build directory? There should be
a libiberty.a there.

-- 
`It's all about bossing computers around. Users have to say "please".
Programmers get to say "do what I want NOW or the hard disk gets it".'
                        -- Richard Heathfield on the nature of programming

On Fri, 24 Aug 2001, HateLinux gibbered:
> own system , tailored to your CPU/ hardware/whims. You learn much more
> about the basic structure of linux, and rely less on distributions (is

Yep :) The system I'm writing this on is built-from-scratch, cross-built
from a 586 (it's an UltraSparc).

So it *can* be done :)

> Redhat really joint owned by microsoft ??? Maybe that's why they
> included GCC 2.96 in version 7.0 ;)     )

Nope, there's no Microsoft ownership :) the GCC-2.96 was there because
it *does* have much better C++ support than 2.95.x --- but unfortunately
it had other downsides, like yet another breaking of C++ binary
compatibility, and miscompilation problems :(

Given that RH employs the largest concentration of GCC expertise on the
planet, they'd be the only people likely to be able to do this and get
away with a reasonable compiler at the end of it :)

-- 
`It's all about bossing computers around. Users have to say "please".
Programmers get to say "do what I want NOW or the hard disk gets it".'
                        -- Richard Heathfield on the nature of programming

Nix wrote:
> 
> On Thu, 23 Aug 2001, Warren Doney stipulated:
> > Mr HateLinux is doing LFS ( http://linuxfromscratch.org )(TFM for static GCC:
> > http://www.linuxfromscratch.org/view/3.0-pre4/ch05-gcc.html ). Needs to be
> > static at that stage, no libs to link to.
> 
> If there are no libs to link to, what is GCC being linked to in order to
> build anything?

Sorry, I should have said no libs on the *partition* it's being put on. LFS
installs the bare minimum to compile everything (statically linked), then you
compile it all "from scratch".

-- 
There is no answer. There is no question. There is only the road, which
stretches out in front of you, an endless night of coffee, technical manuals,
snack food wrappers, disgruntled family members, and hundreds of hours spent
struggling to become adept. Or you can hire a consultant. -Tom Oehser.

On Sun, 26 Aug 2001, Warren Doney uttered the following:
> Nix wrote:
>> 
>> On Thu, 23 Aug 2001, Warren Doney stipulated:
>> > Mr HateLinux is doing LFS ( http://linuxfromscratch.org )(TFM for static GCC:
>> > http://www.linuxfromscratch.org/view/3.0-pre4/ch05-gcc.html ). Needs to be
>> > static at that stage, no libs to link to.
>> 
>> If there are no libs to link to, what is GCC being linked to in order to
>> build anything?
> 
> Sorry, I should have said no libs on the *partition* it's being put on. LFS
> installs the bare minimum to compile everything (statically linked), then you
> compile it all "from scratch".

Ah, right, and LFS assumes that you have an already-built machine of the
same architecture as the one you're bootstrapping. Yes, that's much
simpler; there's no need to bother with the `cross-binutils,
inhibit-libc-cross-compiler, native-libc, cross-compiler,
native-compiler, native-libc, oh-shit-this-fundamental-tool-doesn't-support-
cross-compilation *hack* *hack* *hack*' rain dance.

-- 
`It's all about bossing computers around. Users have to say "please".
Programmers get to say "do what I want NOW or the hard disk gets it".'
                        -- Richard Heathfield on the nature of programming

On Sat, 25 Aug 2001 18:10:35 +1200, in uk.comp.os.linux you wrote:

>Have you tried doing the *book* version of LFS yet?
>
>Packages here:
>http://linuxfromscratch.org/download/packages.shtml
>
>books here:
>ftp://ftp.linuxfromscratch.org/lfs-book/3.0-pre4/
>
>Has been heavily tested & is known to work :)

OK , I downloaded it. Deleted all my old lfs files , made a new file
system , set it up EXACTLY as in this new book. Sad to see over three
weeks work down the drain. I reinstalled zipslack, so I would not get
any bad files.
	The very first compile(static bash) does not work:

root@darkstar:/mnt/lfs/usr/src/bash-2.05# ./configure
--enable-static-link --prefix=/mnt/lfs/usr --bindir=/mnt/lfs/bin
--with-curses

root@darkstar:/mnt/lfs/usr/src/bash-2.05# make
gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"i686"'
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"i686-pc-linux-gnu"'
-DCONF_VENDOR='"pc"' -DSHELL -DHAVE_CONFIG_H
 -D_FILE_OFFSET_BITS=64  -I.  -I. -I./include -I./lib
-I/mnt/lfs/usr/include -g
-O2 -D_FILE_OFFSET_BITS=64  -o mksyntax ./mksyntax.c
In file included from /usr/include/errno.h:36,
                 from ./mksyntax.c:27:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
In file included from /usr/include/bits/posix1_lim.h:126,
                 from /usr/include/limits.h:144,
                 from
/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/include/limits.h:117,
                 from
/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/include/syslimits.h:7,
                 from
/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/include/limits.h:11,
                 from /usr/include/sys/param.h:22,
                 from ./mksyntax.c:346:
/usr/include/bits/local_lim.h:36: linux/limits.h: No such file or
directory
In file included from ./mksyntax.c:346:
/usr/include/sys/param.h:23: linux/limits.h: No such file or directory
/usr/include/sys/param.h:24: linux/param.h: No such file or directory
make: *** [mksyntax] Error 1
root@darkstar:/mnt/lfs/usr/src/bash-2.05#

So I switched to redhat , and tried to compile it from there(I deleted
the /mnt/lfs/usr/src/bash-2.05 folder and re-untarred  it, re
configured it to be safe.)


gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
-L./lib/tilde -L./lib/malloc -L./lib/sh -static -static -rdynamic  -g
-O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o
dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o
flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o
unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o
braces.o bracecomp.o bashhist.o bashline.o siglist.o list.o
stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o
xmalloc.o -lbuiltins -lsh -lreadline -lhistory -lcurses -lglob -ltilde
-lmalloc
/usr/bin/ld: cannot find -lcurses
collect2: ld returned 1 exit status
make: *** [bash] Error 1
21:36:25
/mnt/lfs/usr/src/bash-2.05

root#> rpm -ivh /mnt/cdrom/RedHat/RPMS/ncurses*
package ncurses-5.1-2 is already installed
package ncurses-devel-5.1-2 is already installed
package ncurses4-5.0-2 is already installed

root#> rpm -ivh /mnt/cdrom/RedHat/RPMS/slang-*
package slang-1.4.1-5 is already installed
package slang-devel-1.4.1-5 is already installed
>
>The LFS mailing lists are helpful, so is the IRC channel, but if your question has already been answered, you might just get told to search the mailing list.
	I grepped through the 100Mb of text. There was no help there.

HateLinux wrote:
[........]
> I grepped through the 100Mb of text. There was no help there.

Oh well, if you stick with it, you'll learn the right places to look, which is
9/10ths of the battle. http://www.google.com/linux & a search for "cannot find
lcurses" produced 197 hits, & clicking: 
"More results from archive.linuxfromscratch.org" got me:
http://archive.linuxfromscratch.org/mail-archives/lfsapps/2000/11/0204.html

cd /usr/lib && ln -s libncurses.a libcurses.a 

Thats missing from the 3.0pre4 version of the book :(

You might want to get the 2.4.4 version of the book from:
http://archive.linuxfromscratch.org/lfs-museum/2.4.4/
& compare chapters if you run in to trouble.

As to zipslack, if you were running it in a DOS partition, it would take a very
long time to compile things anyway, & it looks like you are missing some headers
(the .h files).
http://archive.linuxfromscratch.org/lfs-museum/2.4.4/LFS-BOOK-INTEL-2.4.4-HTML/ch05-kernel.html
(note split) explains how you could install a kernel & link to get the headers,
the 3.0pre4 "installing a kernel" chapter explains how you could copy them.

As to the mailing lists & IRC being helpful, I meant for asking questions on/in,
before somebody LART's you for all this cross-posting.

-- 
There is no answer. There is no question. There is only the road, which
stretches out in front of you, an endless night of coffee, technical manuals,
snack food wrappers, disgruntled family members, and hundreds of hours spent
struggling to become adept. Or you can hire a consultant. -Tom Oehser.

Warren Doney (wardon@xtra.co.nz) wrote:
> HateLinux wrote:
> [.......]
> > 
> > Which is exactly the error I had under redhat and gcc-2.96.
> > I'm tired. Just spent 4 hours on this and no where closer to compiling
> > gcc than I was two weeks ago.. I also grepped through the 100
> > megabytes of letters in the lfs mailing lists , but there was no help
> > there. Night all..

> Have you tried doing the *book* version of LFS yet?

> Packages here:
> http://linuxfromscratch.org/download/packages.shtml

> books here:
> ftp://ftp.linuxfromscratch.org/lfs-book/3.0-pre4/

> Has been heavily tested & is known to work :)
Probably premature but LFS-3.0-rc1 is coming out tomorrow (31st August)
It should (fingers and toes crossed) be the same as the 3.0 release
barring the inevitable grammar cock ups what we has maked.  ;-)

(Hopefully Gerard [head bloke] won't make me look foolish by delaying
releasing rc1 now...)

Mark

--
Mark Hymers					BLFS Project Leader
markh@linuxfromscratch.org

Nix ($}xinix{$@esperi.demon.co.uk) wrote:
> Ah, right, and LFS assumes that you have an already-built machine of the
> same architecture as the one you're bootstrapping. Yes, that's much
> simpler; there's no need to bother with the `cross-binutils,
> inhibit-libc-cross-compiler, native-libc, cross-compiler,
> native-compiler, native-libc, oh-shit-this-fundamental-tool-doesn't-support-
> cross-compilation *hack* *hack* *hack*' rain dance.

heh.

One of the things we're working on (well, we will be after LFS-3.0 is out)
is producing a bootable CD which you can use to build LFS from.

Our main target platform is x86 but we do have reports of people using it
on at least Sparc and PowerPPC and we always graciously accept comments
to go in the book for platform-specific notes.

Mark 

--
Mark Hymers				BLFS Project Leader
markh@linuxfromscratch.org