public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael S. Zick <mszick@goquest.com>
To: Andris Pavenis <pavenis@latnet.lv>
Cc: gcc@gcc.gnu.org
Subject: Re: Ada-3.1.1 Makefile Madness
Date: Fri, 09 Aug 2002 06:35:00 -0000	[thread overview]
Message-ID: <02080908251500.00824@localhost.localdomain> (raw)
In-Reply-To: <200208091009.58422.pavenis@latnet.lv>

On Friday 09 August 2002 02:09 am, Andris Pavenis wrote:
> On Friday 09 August 2002 02:07, Michael S. Zick wrote:
> > On Thursday 08 August 2002 02:11 pm, Florian Weimer wrote:
> > > Michael S. Zick <mszick@goquest.com> writes:
> > > > When I reach the "make gnatlib_and_tools" step from within
> > > > <release>/gcc-bld/gcc...
> > >
> > > Your build directory is inside the source directory tree.  Maybe
> > > that's causing the problems you are seeing.
> >
> > Could well be the problem.
> > The instructions do say: "...where objdir is a subdirectory of srcdir ...
> > unsupported..."
>
> It didn't work also for me (target i586-pc-msdosdjgpp). Moving build
> directory out of source directory and specifying absolute path to sources
> worked

On host: i686-pc-linux-gnu (Redhat 7.1 installation style), where original 
software exists in: /usr/bin... & /usr/lib...

Using gnat-3.13p-8 (complete, rpm, binary, install) from www.gnuada.org
which also installs in /usr/bin & /usr/lib...

Ensuring that /usr/bin is first entry in $PATH and specifying: 
export CC=/usr/bin/gnatgcc
Almost works...  If (or when) bootstrap exits with an "ensure you are using a 
compatiable gcc/gnatbind" message... Specify:
export GNATBIND=/usr/bin/gnatbind

Once an initial gcc-3.1.1<ada,c> is built and installed in: <somewhere>/bin & 
<somewhere>/lib...  Specify:
export CC=<somewhere>/gcc
export GNATBIND=<somewhere>/gnatbind
To also get the tools (components) used by the Makefile:bootstrap that don't 
have a variable to hold the current absolute path...  Specify:
export PATH=<somewhere>:$PATH

At which point things get a little iffy during the initial stage of building 
for the stage1 compiler and tools.
The Makefiles hardcode: "../xgcc -B../" used AFTER the building of the stage1 
compiler and tools...

My mind "vapor locks" whenever I try to read these Makefiles - So if a 
Makefile expert could comment on the following:

1) Do away with the use of "GNATBIND" - it only handles "gnatbind" not the 
other gnat tools.
2) Provide ability to specify the absolute paths used during the initial 
building of the stage1 compiler and tools, perhaps like:
export INITIAL_ADA_PATH=<somewhere>
During initial build for stage1 would give:
ADAC=$(INITIAL_ADA_PATH)/$(compiler_that_understands_Ada)
and:
$(INITIAL_ADA_PATH)/gnatbind 
and:
$(INITIAL_ADA_PATH)/<any_other_Ada_tools_used>

I am using binutils-2.13 installed <somewhere>/bin & <somewhere>/lib
I am using the configure options to specify "as" and "ld" to be the 
<somewhere>/bin/as & <somewhere>/bin/ld
BUT, like the problem of not getting matching Ada tools above...

3) Provide ability to specify the absolute paths used during the initial 
building of the stage1 compiler and tools, perhaps like:
export INITIAL_BTOOLS_PATH=<somewhere>/bin
During initial build for stage1 (and other stages if not building new 
binutils in a composite tree), all the non-Ada tools (ar, nm, etc.) would be:
$(INITIAL_BTOOLS_PATH)/nm
$(INITIAL_BTOOLS_PATH)/ar
$(INITIAL_BTOOLS_PATH)/<whatever>
Note: this could also replace the "--with-as= & --with-ld=" configure options.
If building in a composite tree (I am not) - then once the stage1 build is 
complete, those things would become:
$(OUR_NEW_BTOOLS_PATH)/nm
$(OUR_NEW_BTOOLS_PATH)/as
$(OUR_NEW_BTOOLS_PATH)/<whatever>

Of course, all of the above suggestions would have to account for:

HOST_SYSTEM, TARGET_SYSTEM, and BUILD_SYSTEM when not building a native 
compilier / toolset.

Groan.
>
> > BUT - that I was able to get to work with a little file copying.
> >
> > The organization: <something>/<release>/gcc .... with building in:
> > <something>/<bld-gcc>/ .... is a total loser on my machine.
> >
> > The instructions do say: "... some broken make's ... where srcdir is
> > seperate from objdir ... fail".  (No shit!)

I have repeated the bootstrap with the build directory totally seperate from 
the source directory - Once I finish groking this 30MB log file produced by 
"make -d -p bootstrap" I may have more information.

> >
> > So, Question: "What is the minimum REQUIRED version of gnu-make to
> > successfully build gcc-3.1.1<c, ada>?   (Note the "Ada").
>
> make-3.79.1 worked OK for me.

Humm.  I am using make-3.79.1-5 (Redhat-5) there is a make-3.79.1-8 
(Redhat-8), I'll try that also.

Mike
>
> Andris

  reply	other threads:[~2002-08-09  6:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-08  8:09 Michael S. Zick
2002-08-08 12:11 ` Florian Weimer
2002-08-08 16:17   ` Michael S. Zick
2002-08-09  0:11     ` Andris Pavenis
2002-08-09  6:35       ` Michael S. Zick [this message]
2002-08-09 10:00         ` Michael S. Zick
2002-08-09 14:33           ` Michael S. Zick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02080908251500.00824@localhost.localdomain \
    --to=mszick@goquest.com \
    --cc=gcc@gcc.gnu.org \
    --cc=pavenis@latnet.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).