Build of gcc-3.1.1<Ada, C> for Red Hat 7.1

Build of gcc-3.1.1<Ada, C> for Red Hat 7.1

[Michael S. Zick]

1) Native for: 
i686-pc-linux-gnu           

2) gcc -v 
Reading specs from /opt/gcc-3.1.1/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/specs
Configured with: ../gcc-3.1.1/configure \
--prefix=/opt/gcc-3.1.1 \
--enable-version-specific-runtime-libs \
--with-gnu-as \
--with-as=/opt/gcc-3.1.1/bin/as \
--with-gnu-ld \
--with-ld=/opt/gcc-3.1.1/bin/ld \
--enable-threads \
--enable-shared \
--enable-languages=c,ada
Thread model: posix
gcc version 3.1.1                                             

3a) Compiled on:
Linux 2.4.18 #48 SMP Mon Jun 17 16:23:30 CDT 2002 i686 unknown

3b) Compiled against kernel headers: 2.4.2-2 (Red Hat-2)

4) Installed system library: glibc-2.2.2-10 (Red Hat-10)

5) Compile included (and compiled with) binutils-2.13

6) Initial compiler used: gnat-3.13p-8 (full, binary, rpm, install)

7) Untested. But, did triple build into working directories followed
by triple build into install directory.  Your basic, 18 stage (24 stage
if counting binutils), bootstrap.

8) Objectives:
   a) New compiler and binutils co-exist with installed system compiler
      and binutils.
   b) New compiler and binutils built against and build for, the (rather old) 
      installed glibc and kernel-headers.
   c) New compiler and binutils can be selected by prepending their location
      (/opt/gcc-3.1.1/<bin,lib>) to "PATH" and "LD_LIBRARY_PATH".

9) b-zip'd tar-ball of the gcc-3.1.1(Ada & C) with binutils-2.13 binaries to
be posted as soon as I can find a place for them (23MB).  Should be good for 
any Linux, i686, glibc 2.2.2, kernel-header-2.4.2 compatible system.

10) The gcc/INSTALL files could use some help - will post something later.

11) Build hint: Don't let the household Wolf near the power cord while doing
a 24 stage build.

Mike

Re: Build of gcc-3.1.1<Ada, C> for Red Hat 7.1

[Janis Johnson]

On Sat, Aug 10, 2002 at 12:32:30AM -0500, Michael S. Zick wrote:
> 
> 1) Native for: 
> i686-pc-linux-gnu           

Thanks!  Your message is linked from the GCC 3.1 build status page at
http://gcc.gnu.org/gcc-3.1/buildstat.html .

[snip]
> 
> 9) b-zip'd tar-ball of the gcc-3.1.1(Ada & C) with binutils-2.13 binaries to
> be posted as soon as I can find a place for them (23MB).  Should be good for 
> any Linux, i686, glibc 2.2.2, kernel-header-2.4.2 compatible system.
> 
> 10) The gcc/INSTALL files could use some help - will post something later.

Good, thanks.  The source for these is gcc/doc/install.texi.

Janis

Re: Build of gcc-3.1.1<Ada, C> for Red Hat 7.1

[Michael S. Zick]

In reference to:
On Monday 12 August 2002 11:28 am, Janis Johnson wrote:
> On Sat, Aug 10, 2002 at 12:32:30AM -0500, Michael S. Zick wrote:
> > 10) The gcc/INSTALL files could use some help - will post something
> > later.
>
> Good, thanks.  The source for these is gcc/doc/install.texi.
>
Text at: < http://gcc.gnu.org/ml/gcc/2002-08/msg00658.html >

While the week's worth of "Cockpit Errors" I made at the keyboard still fresh 
in my mind...
Thread start at: < http://gcc.gnu.org/ml/gcc/2002-08/msg00457.html >

I am considering a two step process:
1) Clarify those install directions for GCC in a manner workable both with 
current GCC requirements and the current workings of other GNU-projects.
<panic>
2) Do a major re-think of those makefiles.  <panic> Actually, what I have in 
mind will re-use about 99.44% of the existing makefiles </panic>.  The 
process will remain the same, only the internal structure will become more 
general.

When I speak here of "makefiles" I naturally, also, mean those files the 
user's Makefile(s) is/are built from.

Item (2) above is at the "Comment and Reaction" stage for now.

Dealing with item (1) first - a description of the situation as I found it 
from the prospective of a "First Time Builder" of GCC and then a description 
of the sort of "Recommendation(s)" I would like to include in the "Install" 
directions.

Historically (and currently for some GNU projects) where the "<release_name>" 
is the highest level directory in the tar-ball downloaded...

Structure A: (where installation instructions say enter: "./configure")
<some_where>/<release_name>/configure.sh
I.E: Building in the <release_name> directory.

Structure B: (where installation instructions say enter: "../configure")
<some_where>/<release_name>/configure.sh
<some_where>/<release_name>/<build_directory>

Structure C: (where installation instructions say enter: 
"<src_dir>/configure")

<some_where>/<release_name>/configure.sh
<some_where>/<optionally_ a_built_for_directory>/<build_directory>

Currently, (as of the gcc-3.1.1 makefiles, when building (at least) <c, 
Ada>), directory structure (C) is REQUIRED.
(Which means that a "VPATH" capable version of "make" is also REQUIRED.)

Note: If you have a "VPATH" capable version of "make" (at least if you have a 
"VPATH" capable version of GNU-make) then other GNU-projects whose 
"makefiles" are written for either structure (A) or structure (B) but also 
set "VPATH" also work for structure (C).

 - * - * - * -

What I would like to include in the installation instructions is a: 
"Recommended Directory Structure" which would look like this -

Having installed your sources from the release tar-balls, your source 
directory structure will look like:
<some_where>/<release_name>
where "<release_name>" is created by the (FSF) tar-ball you just used.

Now create a directory for building the software into which is parallel to 
(and dis-joint from) the <release_name> directory.  You may use a single 
directory structure for the build, or multiple directories if doing multiple 
builds.
That is, make your build directory structure look like:
<some_where>/<build_directory>
OR:
<some_where>/<any_number_of_build_descriptive_directory(ies)/<build_directory>

Make that build directory your current directory and enter (the correct 
expansion of): <some_where>/<release_name>/configure

 - * - * - * -

Using the building of gcc-3.1.1 as an example, this would give a "source 
directory" structure like so (when combined with the other efforts being 
undertaken to have a "Software Requirements" page(s)):

<some_where>/<gcc-3.1.1>

If the system doesn't have a usable "make":
<some_where>/<make-3.79.1>

If user wants documentation built and system doesn't have a usable "makeinfo":
<some_where>/<texinfo-4.1>

If user wants a new set of "binutils" tools (perhaps to support the 
"--new-c++-abi" option):
<some_where>/<binutils-2.13>

If user wants a new gdb:
<some_where>/<gdb-5.2.1>

And so on, and so forth; for whatever the user needs to support a native 
build, cross build (double-cross) or a Canadian cross build (triple-cross).
All the while maintaining the ability to start the build using one or more 
"any ol' compiler(s)" and set(s) of tools.

Where all of the "<some_where>" portions of the source directory paths may be 
the same, relative, or different, absolute paths as long as they meet the 
"dis-joint" requirement.

 - * - * - * - * -

Moving forward, to "pre-think" item (2)...

Retain the historical sequence of: "configure", "make bootstrap", ["make 
check"], "make install"...

Add the targets for "make prep" and "make prep-check" - perhaps also add a 
single new target "make easy".

"make prep":
Tries to Grok the system's directory structure for the sources of everything 
needed, beginning with the recommended directory structure.  Writes a "fill 
in the blanks" script file WITH DIRECTIONS for anything it can't resolve a 
single path too (multiple versions of a needed source, versions on a remote 
system that isn't mounted when the command is run, etc.)

[Avoiding the case where messges like: "Can't make the documents because your 
makeinfo is too old" that fly by among a zillion other messages.]

After the user updates the generated file:

"make prep-check":
Will simply (??) check for a usable source(s) directory structure based on 
the user's updates to the path information of (above) generated file.
Ending with directions to the user to enter either:
"./configure" or "./configure --site=<generated_and_edited_filename>"

At which point the "First Time Builder" joins the path taken by the "Old 
Pros".

Comments?  Suggestions?

Mike

PS: I don't think the changes to the install instructions will take a 
copyright assignment - those are trival clarifications.  The changes to all 
of the "makefile" stuff are fairly extensive, so I need that link to the 
copyright assignment form please.

GCC Install Instructions

[Michael S. Zick]

Sorry for the duplicate post - I forgot to change the subject and address 
lines.

In reference to:
On Monday 12 August 2002 11:28 am, Janis Johnson wrote:
> On Sat, Aug 10, 2002 at 12:32:30AM -0500, Michael S. Zick wrote:
> > 10) The gcc/INSTALL files could use some help - will post something
> > later.
>
> Good, thanks.  The source for these is gcc/doc/install.texi.
>
Text at: < http://gcc.gnu.org/ml/gcc/2002-08/msg00658.html >

While the week's worth of "Cockpit Errors" I made at the keyboard still fresh 
in my mind...
Thread start at: < http://gcc.gnu.org/ml/gcc/2002-08/msg00457.html >

I am considering a two step process:
1) Clarify those install directions for GCC in a manner workable both with 
current GCC requirements and the current workings of other GNU-projects.
<panic>
2) Do a major re-think of those makefiles.  <panic> Actually, what I have in 
mind will re-use about 99.44% of the existing makefiles </panic>.  The 
process will remain the same, only the internal structure will become more 
general.

When I speak here of "makefiles" I naturally, also, mean those files the 
user's Makefile(s) is/are built from.

Item (2) above is at the "Comment and Reaction" stage for now.

Dealing with item (1) first - a description of the situation as I found it 
from the prospective of a "First Time Builder" of GCC and then a description 
of the sort of "Recommendation(s)" I would like to include in the "Install" 
directions.

Historically (and currently for some GNU projects) where the "<release_name>" 
is the highest level directory in the tar-ball downloaded...

Structure A: (where installation instructions say enter: "./configure")
<some_where>/<release_name>/configure.sh
I.E: Building in the <release_name> directory.

Structure B: (where installation instructions say enter: "../configure")
<some_where>/<release_name>/configure.sh
<some_where>/<release_name>/<build_directory>

Structure C: (where installation instructions say enter: 
"<src_dir>/configure")

<some_where>/<release_name>/configure.sh
<some_where>/<optionally_ a_built_for_directory>/<build_directory>

Currently, (as of the gcc-3.1.1 makefiles, when building (at least) <c, 
Ada>), directory structure (C) is REQUIRED.
(Which means that a "VPATH" capable version of "make" is also REQUIRED.)

Note: If you have a "VPATH" capable version of "make" (at least if you have a 
"VPATH" capable version of GNU-make) then other GNU-projects whose 
"makefiles" are written for either structure (A) or structure (B) but also 
set "VPATH" also work for structure (C).

 - * - * - * -

What I would like to include in the installation instructions is a: 
"Recommended Directory Structure" which would look like this -

Having installed your sources from the release tar-balls, your source 
directory structure will look like:
<some_where>/<release_name>
where "<release_name>" is created by the (FSF) tar-ball you just used.

Now create a directory for building the software into which is parallel to 
(and dis-joint from) the <release_name> directory.  You may use a single 
directory structure for the build, or multiple directories if doing multiple 
builds.
That is, make your build directory structure look like:
<some_where>/<build_directory>
OR:
<some_where>/<any_number_of_build_descriptive_directory(ies)/<build_directory>

Make that build directory your current directory and enter (the correct 
expansion of): <some_where>/<release_name>/configure

 - * - * - * -

Using the building of gcc-3.1.1 as an example, this would give a "source 
directory" structure like so (when combined with the other efforts being 
undertaken to have a "Software Requirements" page(s)):

<some_where>/<gcc-3.1.1>

If the system doesn't have a usable "make":
<some_where>/<make-3.79.1>

If user wants documentation built and system doesn't have a usable "makeinfo":
<some_where>/<texinfo-4.1>

If user wants a new set of "binutils" tools (perhaps to support the 
"--new-c++-abi" option):
<some_where>/<binutils-2.13>

If user wants a new gdb:
<some_where>/<gdb-5.2.1>

And so on, and so forth; for whatever the user needs to support a native 
build, cross build (double-cross) or a Canadian cross build (triple-cross).
All the while maintaining the ability to start the build using one or more 
"any ol' compiler(s)" and set(s) of tools.

Where all of the "<some_where>" portions of the source directory paths may be 
the same, relative, or different, absolute paths as long as they meet the 
"dis-joint" requirement.

 - * - * - * - * -

Moving forward, to "pre-think" item (2)...

Retain the historical sequence of: "configure", "make bootstrap", ["make 
check"], "make install"...

Add the targets for "make prep" and "make prep-check" - perhaps also add a 
single new target "make easy".

"make prep":
Tries to Grok the system's directory structure for the sources of everything 
needed, beginning with the recommended directory structure.  Writes a "fill 
in the blanks" script file WITH DIRECTIONS for anything it can't resolve a 
single path too (multiple versions of a needed source, versions on a remote 
system that isn't mounted when the command is run, etc.)

[Avoiding the case where messges like: "Can't make the documents because your 
makeinfo is too old" that fly by among a zillion other messages.]

After the user updates the generated file:

"make prep-check":
Will simply (??) check for a usable source(s) directory structure based on 
the user's updates to the path information of (above) generated file.
Ending with directions to the user to enter either:
"./configure" or "./configure --site=<generated_and_edited_filename>"

At which point the "First Time Builder" joins the path taken by the "Old 
Pros".

Comments?  Suggestions?

Mike

PS: I don't think the changes to the install instructions will take a 
copyright assignment - those are trival clarifications.  The changes to all 
of the "makefile" stuff are fairly extensive, so I need that link to the 
copyright assignment form please.

Re: Build of gcc-3.1.1<Ada, C> for Red Hat 7.1

[Gerald Pfeifer]

On Tue, 13 Aug 2002, Michael S. Zick wrote:
> PS: I don't think the changes to the install instructions will take a
> copyright assignment - those are trival clarifications.  The changes to all
> of the "makefile" stuff are fairly extensive, so I need that link to the
> copyright assignment form please.

Please find what I believe to be the appropriate form below.

Gerald

PS: I'm still disappointed that RMS requested us to remove these forms
from our web site.

====================== CUT ================

Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]