🚀 go-pugleaf

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