Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Robert Dewar]

> I don't understand this. I just did a clean configure and make bootstrap
> on sparc-sun-solaris2.8 without problems. The bootstrap compiler was
> GNAT 3.13p1. (I use the C compiler that comes with the GNAT 
> distribution.)
> 

Note that this is important (to use the C compiler that comes with GNAT,
otherwise you may have incompatible versions of GNAT and C. We have noted
this problem in a previous thread).

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Christian Cornelssen]

Hi,

On Tue, 28 Jan 2003, Geert Bosch wrote:

> I don't understand this. I just did a clean configure and make bootstrap
> on sparc-sun-solaris2.8 without problems. The bootstrap compiler was
> GNAT 3.13p1. (I use the C compiler that comes with the GNAT
> distribution.)

On Tue, 28 Jan 2003, Robert Dewar wrote:

> Note that this is important (to use the C compiler that comes with GNAT,
> otherwise you may have incompatible versions of GNAT and C. We have noted
> this problem in a previous thread).

On "my" platform (doko's i686-pc-linux-gnu / Debian):

$ gnatgcc -v -x ada /dev/null
Reading specs from /usr/lib/gcc-lib/i486-linux/2.8.1/specs
gcc version 2.8.1
 /usr/lib/gcc-lib/i486-linux/2.8.1/gnat1 -quiet -dumpbase null.ada /dev/null -o /tmp/ccn8cpyx.s
gnat1: Cannot find: null
$ gnatbind -v /dev/null

GNATBIND 3.14p (20010503) Copyright 1995-2001 Free Software Foundation, Inc.

Binding: null.ali
gnatbind: Cannot find: null.ali

I have also checked that gnatgcc and gnatbind belong to the same
Debian gnat package, and verified the md5sums.

Anything invalid?  Note that bootstrapping Ada works for GCC >= 3.3.

Regards,

Christian Cornelssen

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Christian Cornelssen]

On Tue, 28 Jan 2003, Christian Cornelssen wrote:

> On "my" platform (doko's i686-pc-linux-gnu / Debian):
>
> $ gnatgcc -v -x ada /dev/null
> Reading specs from /usr/lib/gcc-lib/i486-linux/2.8.1/specs
> gcc version 2.8.1
> [...]
> $ gnatbind -v /dev/null
>
> GNATBIND 3.14p (20010503) Copyright 1995-2001 Free Software Foundation, Inc.
>
> I have also checked that gnatgcc and gnatbind belong to the same
> Debian gnat package, and verified the md5sums.
>
> Anything invalid?  Note that bootstrapping Ada works for GCC >= 3.3.

My idea was that `gnat1drv.ali' had not been regenerated by the stage1
compiler, but the following log excerpts proved me wrong:

gnatgcc -c -march=i686 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional     -W -Wall -gnatpg -gnata -I- -I. -I/home/other/ccorn/SOURCES/gcc/gcc/ada /home/other/ccorn/SOURCES/gcc/gcc/ada/gnat1drv.adb
gnatbind -C -I- -I. -I/home/other/ccorn/SOURCES/gcc/gcc/ada -o b_gnat1.c -n gnat1drv.ali
[...no problems...]
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -march=i686 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long    -W -Wall -gnatpg -gnata -I- -I. -I/home/other/ccorn/SOURCES/gcc/gcc/ada /home/other/ccorn/SOURCES/gcc/gcc/ada/gnat1drv.adb
stage1/gnatbind -C -I- -I. -I/home/other/ccorn/SOURCES/gcc/gcc/ada -o b_gnat1.c -n gnat1drv.ali
fatal error: file gnat1drv.ali is incorrectly formatted

I have not looked at the particular contents of `gnat1drv.ali'.
(Meanwhile, I have deleted the build tree to free space for other test
builds.)  Do you have an idea what might be wrong, though?

Regards,

Christian Cornelssen

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Geert Bosch]

On Friday, Jan 31, 2003, at 12:32 America/New_York, Christian 
Cornelssen wrote:

> I have not looked at the particular contents of `gnat1drv.ali'.
> (Meanwhile, I have deleted the build tree to free space for other test
> builds.)  Do you have an idea what might be wrong, though?

For troubleshooting these kind of problems, I would definitely recommend
that you use "-gnatv", as that will give you the definite version of the
gnat1 executable used to build the .o and .ali files.

   -Geert

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Gabriel Dos Reis]

Geert Bosch <bosch@gnat.com> writes:

| Bootstrap will take a while. I'll report back after it finishes (or
| fails)
| and in case of success I'll make the fix on the branch.

Thanks,

-- Gaby

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Geert Bosch]

On Tuesday, Jan 28, 2003, at 14:46 America/New_York, Christian 
Cornelssen wrote:

> I have tried it on i686-pc-linux-gnu, but Ada bootstrap fails as
> before.  It seems that `gnat1drv.ali' must be cleaned between stages,
> but isn't.  See the attached log file for details.  I am not quite
> familiar with the hairy bootstrap details; perhaps just some *clean
> target needs to be updated.
>
> However, this does not mean that the new GNATBIND setting is wrong;
> in `gcc/ada/Makefile.in', the new setting has been used before, and I
> guess that `gcc/ada/Make-lang.in' has just missed the corresponding
> update.  The bootstrap failure looks like before, not worse...
>

I don't understand this. I just did a clean configure and make bootstrap
on sparc-sun-solaris2.8 without problems. The bootstrap compiler was
GNAT 3.13p1. (I use the C compiler that comes with the GNAT 
distribution.)

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Christian Cornelssen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 893 bytes --]

Hello,

On Tue, 28 Jan 2003, Geert Bosch wrote:

> > [...]
> > -GNATBIND = gnatbind
> > [...]
> > +GNATBIND = $(STAGE_PREFIX)gnatbind -C
> > [...]
>
> This might well be the right solution. I'm testing this now on a freshly
> checked out gcc-3_2-branch, using GNAT 3.13p1 as a base compiler.

I have tried it on i686-pc-linux-gnu, but Ada bootstrap fails as
before.  It seems that `gnat1drv.ali' must be cleaned between stages,
but isn't.  See the attached log file for details.  I am not quite
familiar with the hairy bootstrap details; perhaps just some *clean
target needs to be updated.

However, this does not mean that the new GNATBIND setting is wrong;
in `gcc/ada/Makefile.in', the new setting has been used before, and I
guess that `gcc/ada/Make-lang.in' has just missed the corresponding
update.  The bootstrap failure looks like before, not worse...

Regards,

Christian Cornelssen

[-- Attachment #2: Type: APPLICATION/x-gunzip, Size: 33048 bytes --]

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Geert Bosch]

On Tuesday, Jan 28, 2003, at 09:52 America/New_York, Christian 
Cornelssen wrote:

> Sure?  A "diff -u" on `gcc/ada/Make-lang.in' from the 3.2 and 3.3 
> branches
> yields
>
> [...]
> -GNATBIND = gnatbind
> [...]
> +GNATBIND = $(STAGE_PREFIX)gnatbind -C
> [...]

This might well be the right solution. I'm testing this now on a freshly
checked out gcc-3_2-branch, using GNAT 3.13p1 as a base compiler.
Actually, I think this TN's subject was a bit misleading: the issue
is about invoking wrong gnatbind, not using a compiler that is too old.

Bootstrap will take a while. I'll report back after it finishes (or 
fails)
and in case of success I'll make the fix on the branch.

   -Geert

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Christian Cornelssen]

Hi,

On Tue, 28 Jan 2003, Richard Kenner wrote:

>     +GNATBIND = $(STAGE_PREFIX)gnatbind -C
>
> Clearly STAGE_PREFIX is needed.  I don't know how it ever got out of
> there.  When "gnatbind" was shown, I assumed this was the *initial*
> compilation, but certainly the stage2 compilation needs to invoke it with
> stage1/gnatbind.

Thanks, I'll try that and post the result.

Regards,

Christian Cornelssen

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Richard Kenner]

    +GNATBIND = $(STAGE_PREFIX)gnatbind -C

Clearly STAGE_PREFIX is needed.  I don't know how it ever got out of
there.  When "gnatbind" was shown, I assumed this was the *initial*
compilation, but certainly the stage2 compilation needs to invoke it with
stage1/gnatbind.

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Christian Cornelssen]

Hi,

On Tue, 28 Jan 2003, Richard Kenner wrote:

>     It would be helpful if you (GNAT folks) could investigate this issue.
>     Fundamentally, it boils down to the following: In the command invocation
>
>        gnatbind -I. [args]
>
>     gnatbind gets resolved to whatever is found in $PATH
>
> It is *supposed* to get resolved to $PATH when it is invoked in that way.

Sure?  A "diff -u" on `gcc/ada/Make-lang.in' from the 3.2 and 3.3 branches
yields

[...]
-GNATBIND = gnatbind
[...]
+GNATBIND = $(STAGE_PREFIX)gnatbind -C
[...]

But I have not tried whether this alone would help.

Regards,

Christian Cornelssen

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|     It would be helpful if you (GNAT folks) could investigate this issue.
|     Fundamentally, it boils down to the following: In the command invocation
| 
|        gnatbind -I. [args]
| 
|     gnatbind gets resolved to whatever is found in $PATH
| 
| It is *supposed* to get resolved to $PATH when it is invoked in that way.

That assumption seems to be the root of many problems.

-- Gaby

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Richard Kenner]

    It would be helpful if you (GNAT folks) could investigate this issue.
    Fundamentally, it boils down to the following: In the command invocation

       gnatbind -I. [args]

    gnatbind gets resolved to whatever is found in $PATH

It is *supposed* to get resolved to $PATH when it is invoked in that way.

Re: [3.2] Can ada/6160 be cured from 3.3 or trunk?

[Gabriel Dos Reis]

Christian Cornelssen <ccorn@cs.tu-berlin.de> writes:

| Hello,
| 
| as in PR ada/6160, I cannot bootstrap Ada from the gcc-3_2-branch
| because my gnatgcc version is 2.8.1.  gcc-3_3-branch and mainline
| do not have that problem.
| 
| Is there an easy fix that can be merged to the 3.2 branch?
| There is some need for it because I (and probably others)
| want to test some patches to the Ada Makefile suite.

Robert,

  Yet another instance of the bootstrap problem I got this night and
what I just described in my recent mail.
It would be helpful if you (GNAT folks) could investigate this issue.
Fundamentally, it boils down to the following: In the command invocation

   gnatbind -I. [args]

gnatbind gets resolved to whatever is found in $PATH -- most of the
time, the wrong tool.  I believe a fix would be to say something like 

  ./gnatbind -I [args]

or
  stage1/gnatbind -I [args]

(same for helper utilities)

Well, I may be wrong but I believe that should be a good start for the
fix.

-- Gaby