gcc 3.4 - gnatmake has wrong gcc name

gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

Hi,

I now have managed to build RTEMS toolsets including
Ada for multiple CPU families (arm, i386, m68k,
mips, sparc, and powerpc).  I am focusing more detailed
testing on the sparc right now since I have rewritten
sparc/config/rtemself.h.  The toolset is capable
of compiling RTEMS so it looks OK BUT...

My target is sparc-rtems4.7.  sparc-rtems4.7-gnatmake
is confused about the name of the target gcc.  It is
failing with this:

sparc-gcc -c -O -gnata -gnatE -gnato -g 
-B/opt/gcc-3.4-test/sparc-rtems4.7/erc32/lib -specs bsp_specs -qrtems 
-mcpu=cypress hello.adb
sparc-rtems4: error, unable to locate sparc-gcc

Note that the name of the gcc is wrong and that the name
used in the error message is also wrong.

The sdefault.adb has this:

   S0 : constant String := "/opt/gcc-3.4-test/";
    S1 : constant String := 
"/opt/gcc-3.4-test/lib/gcc/sparc-rtems4.7/3.4.0/adainclude/";
    S2 : constant String := 
"/opt/gcc-3.4-test/lib/gcc/sparc-rtems4.7/3.4.0/adalib/";
    S3 : constant String := "sparc-unknown-rtems4.7/";
    S4 : constant String := 
"/opt/gcc-3.4-test/lib/gcc/sparc-rtems4.7/3.4.0/";

S0, S1, S3, adn S4 are OK.  S3 is the canonical target name so
is probably OK but it must be being parsed somewhere and
getting confused.

Advice and pointers appreciated.

--joel

Re: gcc 3.4 - gnatmake has wrong gcc name

[Jim Wilson]

Joel Sherrill wrote:
> sparc-gcc -c -O -gnata -gnatE -gnato -g 
> -B/opt/gcc-3.4-test/sparc-rtems4.7/erc32/lib -specs bsp_specs -qrtems 
> -mcpu=cypress hello.adb
> sparc-rtems4: error, unable to locate sparc-gcc

> Advice and pointers appreciated.

I suggest looking at the source.

The routines in question here are Find_Program_Name and Program_Name in 
ada/osint.adb.

Find_Program_Name gets the executable name, removes everything up to the 
last slash, which gives us a program name without any leading path 
components.

It then removes everything after the last dot.  This is probably 
assuming that if there is a dot, then there must be some extension like 
.exe to be stripped off.  This can be see in the above.  Note the error 
message says sparc-rtems4, not sparc-rtems4.7-gnatmake because the 
supposed file name extension has been removed.

Program_name then removes everything after the last dash, which should 
be gnatmake, but in your case is rtems4.  This leaves just sparc-.  Then 
it appends gcc giving sparc-gcc.

The Program_Name ("gcc") call is in make.adb.

I haven't tried to verify any of this with a build or debugger.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 3.4 - gnatmake has wrong gcc name

[Arnaud Charlet]

> I haven't tried to verify any of this with a build or debugger.

That's the correct explanation.

Arno

Re: gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

Jim Wilson wrote:

> Joel Sherrill wrote:

> The routines in question here are Find_Program_Name and Program_Name in 
> ada/osint.adb.
> 
> Find_Program_Name gets the executable name, removes everything up to the 
> last slash, which gives us a program name without any leading path 
> components.
> 
> It then removes everything after the last dot.  This is probably 
> assuming that if there is a dot, then there must be some extension like 
> .exe to be stripped off.  This can be see in the above.  Note the error 
> message says sparc-rtems4, not sparc-rtems4.7-gnatmake because the 
> supposed file name extension has been removed.
> 
> Program_name then removes everything after the last dash, which should 
> be gnatmake, but in your case is rtems4.  This leaves just sparc-.  Then 
> it appends gcc giving sparc-gcc.
> 
> The Program_Name ("gcc") call is in make.adb.
> 
> I haven't tried to verify any of this with a build or debugger.

I didn't do this because I remembered having submitted a patch for
similar behvior in the gnattools years ago and wanted to find it to
before doing the above.

I think your description of the behavior is correct.  I can fix it
but need to know what the real behavior should be.  Would the
Ada equivalent of name() in this shell script be the desired behavior?

--------------------------------------------------------------------
#! /bin/sh

name()
{
  # Equivalent of Find_Program_Name
  progname=`echo $1 | sed -e 's/\.exe$//'`
  # Equivalent of Program_Name
  target=`echo $progname | sed -e 's/-[a-zA-Z0-9]*$//'`
  echo ${target}-$2
}

name sparc-rtems-gnatmake gcc
name sparc-rtems4.7-gnatmake gcc
name sparc-rtems-gnatmake.exe gcc
name sparc-rtems4.7-gnatmake.exe gcc
---------------------------------------------------------------------

My impression is that Find_Program_Name is broken for
versioned target names with '.' in them and that it really
needs to be removing a known set of extensions.  Is there anything
other than .exe$ that needs to be taken off?

--joel

Re: gcc 3.4 - gnatmake has wrong gcc name

[Jim Wilson]

Joel Sherrill wrote:
> My impression is that Find_Program_Name is broken for
> versioned target names with '.' in them and that it really
> needs to be removing a known set of extensions.  Is there anything
> other than .exe$ that needs to be taken off?

It looks like .exe is the only thing that current targets use.

However, there are configure/Makefile variables to support other 
extensions.  See ac_exeext in configure. exeext in Makefile.  It would 
be better if you could compiled in the exeext value instead of assuming 
it is .exe.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

Jim Wilson wrote:
> Joel Sherrill wrote:
> 
>> My impression is that Find_Program_Name is broken for
>> versioned target names with '.' in them and that it really
>> needs to be removing a known set of extensions.  Is there anything
>> other than .exe$ that needs to be taken off?
> 
> 
> It looks like .exe is the only thing that current targets use.
> 
> However, there are configure/Makefile variables to support other 
> extensions.  See ac_exeext in configure. exeext in Makefile.  It would 
> be better if you could compiled in the exeext value instead of assuming 
> it is .exe.

Thanks Jim.

It is the end of the day and I don't have the EXEEXT part worked in yet
but here is a patch which seems to work correctly for just .exe's.
How does this look?

Would an Ada maintainer please comment on this patch and how they
feel about using EXEEXT since that will require adding some to
sdefault.adb.

Index: osint.adb
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ada/osint.adb,v
retrieving revision 1.16
diff -u -r1.16 osint.adb
--- osint.adb   5 Jan 2004 15:20:45 -0000       1.16
+++ osint.adb   18 Mar 2004 23:39:21 -0000
@@ -1006,12 +1006,17 @@
           end if;
        end loop;

-      for J in reverse Cindex1 .. Cindex2 loop
-         if Command_Name (J) = '.' then
-            Cindex2 := J - 1;
-            exit;
+      --  Command_Name(Cindex1 .. Cindex2) is now the equivalent of the
+      --  POSIX command "basename argv[0]"
+
+      --  Now strip off any executable extension (usually nothing or .exe)
+      --  but formally reported by autoconf in the variable EXEEXT
+
+      if (Cindex2 - Cindex1) >= 3 then
+         if Command_Name (Cindex2 - 3 .. Cindex2) = ".exe" then
+            Cindex2 := Cindex2 - 3;
           end if;
-      end loop;
+      end if;

        Name_Len := Cindex2 - Cindex1 + 1;
        Name_Buffer (1 .. Name_Len) := Command_Name (Cindex1 .. Cindex2);

--joel

Re: gcc 3.4 - gnatmake has wrong gcc name

[Arnaud Charlet]

> Would an Ada maintainer please comment on this patch and how they
> feel about using EXEEXT since that will require adding some to
> sdefault.adb.

No particular feeling, except that it ought to be simple. We don't want to
add too much extra complexity for a very marginal usage (and one unlikely
to happen in practise on any Ada supported host).

We used to check for .exe, but changed that a while ago, because it didn't
work under VMS (apparently because of version numbers), so this would likely
create a regression under VMS.

Richard (Kenner), do you remember this change ?
date: 1996/11/24 16:17:57;  author: kenner;  state: Exp;  lines: +28 -21
(Write_Program_Name): Replace previous change with code that will
 also strip off version number in VMS.


Arno

Re: gcc 3.4 - gnatmake has wrong gcc name

[Jim Wilson]

On Thu, 2004-03-18 at 23:53, Arnaud Charlet wrote:
> No particular feeling, except that it ought to be simple. We don't want to
> add too much extra complexity for a very marginal usage (and one unlikely
> to happen in practise on any Ada supported host).

Configure names with dots in them need to work.  Sometimes minor OS
revisions can contain significant changes.  We can't just tell people
that they can't use dots in configure names anymore if they want to use
Ada.

> We used to check for .exe, but changed that a while ago, because it didn't
> work under VMS (apparently because of version numbers), so this would likely
> create a regression under VMS.

Perhaps we should try a different tack here.  Find the "gnatmake" in the
program name and drop everything after that.  This assumes gnatmake will
never be renamed, but that doesn't seem like much of a risk.

Or alternatively, program in the target tuple at configure/compile
time.  That way you don't have to try to compute it at run time.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 3.4 - gnatmake has wrong gcc name

[Arnaud Charlet]

> Configure names with dots in them need to work.  Sometimes minor OS
> revisions can contain significant changes.  We can't just tell people
> that they can't use dots in configure names anymore if they want to use
> Ada.

They work, since you can always call cross-gcc independently, and also
call gnatmake --GCC= to work around this limitation, this we're only talking
about a (desirable) improvement. That's why I'd rather get it right rather
than half baked.

> Perhaps we should try a different tack here.  Find the "gnatmake" in the
> program name and drop everything after that.  This assumes gnatmake will
> never be renamed, but that doesn't seem like much of a risk.

Possibly, although this wouldn't work with --program-suffix.
We don't support it for Ada anyway (see PR ada/864), but it would be nice
to take it into account as well if possible.

Arno

Re: gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

Arnaud Charlet wrote:

>>Would an Ada maintainer please comment on this patch and how they
>>feel about using EXEEXT since that will require adding some to
>>sdefault.adb.
>>    
>>
>
>No particular feeling, except that it ought to be simple. We don't want to
>add too much extra complexity for a very marginal usage (and one unlikely
>to happen in practise on any Ada supported host).
>
>  
>
It is hard to call anything related to proper parsing of target names in 
gcc marginal usage.  Any
target name in ggcc which ends like -OS*) is subject to this breakage.

>We used to check for .exe, but changed that a while ago, because it didn't
>work under VMS (apparently because of version numbers), so this would likely
>create a regression under VMS.
>
>Richard (Kenner), do you remember this change ?
>date: 1996/11/24 16:17:57;  author: kenner;  state: Exp;  lines: +28 -21
>(Write_Program_Name): Replace previous change with code that will
> also strip off version number in VMS.
>
>  
>
Looks to me that hist handling of VMS versioning is breaking all 
versioned hosts.  What is
the regular pattern for their versioned names?

>Arno
>  
>

Re: gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

Arnaud Charlet wrote:

>>Configure names with dots in them need to work.  Sometimes minor OS
>>revisions can contain significant changes.  We can't just tell people
>>that they can't use dots in configure names anymore if they want to use
>>Ada.
>>    
>>
>
>They work, since you can always call cross-gcc independently, and also
>call gnatmake --GCC= to work around this limitation, this we're only talking
>about a (desirable) improvement. That's why I'd rather get it right rather
>than half baked.
>  
>

I may be being anal retentive here but if none of the tools have been 
moved around or renamed,
it is broken for the user to have to specify --GCC.  Wouldn't we all 
think it was broken if after
installing gcc, you had to pass a command line option to tell it where 
the cc1 or gnat1 it should
use is located?

>>Perhaps we should try a different tack here.  Find the "gnatmake" in the
>>program name and drop everything after that.  This assumes gnatmake will
>>never be renamed, but that doesn't seem like much of a risk.
>>    
>>
>
>Possibly, although this wouldn't work with --program-suffix.
>We don't support it for Ada anyway (see PR ada/864), but it would be nice
>to take it into account as well if possible.
>
>  
>
or program_transform_name which (if still around) is arbitrarily complex.

This is like a trip in the wayback machine.  I fixed this problem in 
1997 against 3.10p.
The patch released with RTEMS 4.0.0 is still on the rtems ftp server.  
There is other
stuff in this patch but the part to Make-lang.in to handle 
program_transform_name
is still easy to read and reapply today.  It installs all of the gnat 
tools with the same type of logic
that gcc does (or at least did in gcc 2.8.1) and .  It adds Gcc_Name, 
Gnatbind_Name, and
Gnatlink_Name to sdefault.adb.  Doing it this way, there isn't any need 
for regular
expression string manipulation since you know the name the tool was 
actually installed with.

http://www.rtems.com/ftp/pub/rtems/releases/4.0.0/ada_tools/gnat-3.10p-rtems-diff.971106

with program_transform_name, someone COULD replace gnat with ada in all 
the tool
names and this would break the string manipulation. 

Prepending the Directory part to the canonical tool name would be a 100% 
solution since
my 3.10p patch required the cross tools to be in your path.

>Arno
>  
>

--joel

Re: gcc 3.4 - gnatmake has wrong gcc name

[Arnaud Charlet]

> It is hard to call anything related to proper parsing of target names in 
> gcc marginal usage.  Any
> target name in ggcc which ends like -OS*) is subject to this breakage.

You're confused: I was replying to the EXEEXT part. What is marginal is
having a EXEEXT different from "" or ".exe"

> Looks to me that hist handling of VMS versioning is breaking all 
> versioned hosts.  What is
> the regular pattern for their versioned names?

I don't know. I believe it's ";version", e.g. GCC.EXE;2, but I'm no
VMS expert.

Arno

Re: gcc 3.4 - gnatmake has wrong gcc name

[Gabriel Paubert]

On Fri, Mar 19, 2004 at 06:17:46AM -0600, Joel Sherrill wrote:
> Looks to me that hist handling of VMS versioning is breaking all 
> versioned hosts.  What is
> the regular pattern for their versioned names?

I believe something like the following (for grep-E or awk):

	.*\..*\;[0-9]+

would work, but I'm not an expert at regular expressions, 
resorting far too often to trial and error until it works
for the specific case at hand.

So here are the rules (I'm still using VMS on a VAX
a bit too much for my taste).

All filenames are of the form: 

	name.type;version

after stripping the possible node::device:[directory]
preceding them.

Name amd type are 1 to 38 characters, case is ignored, and
very few characters are accepted outside of digits and letters. 
Only one dot is allowed, between name and type. 

version is string of decimal digits, valid values
for an existing file are 1 to 32767, but the file 
system also interprets 0 as the latest version,  -1 
as next to last, etc... 

Finally you can use either a semicolon or a dot
between the name and the type when the type is specified.
(To print a file without type on the screen, you have
to type "TYPE FILE.", otherwise it will try to use a
default extension for the command, .LIS in this case AFAIR)

In directory listings and file searches, the dot and the semicolon
are always present, letters are always in uppercase. (But you can
create a file called ".;1", with empty name and type fields, which 
causes some funny things when an ftp program tries to transfer
it to a Unix machine and strips the ;1 part).

	Regards,
	Gabriel

P.S.: Just reading how to open a file on VMS with the medium 
level calls (RMS) will make your head hurt. Trying to understand
the low level calls will make you insane.
	

Re: gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

OK.. I think I have done it.  I have filed PR14665 with
a patch which (I hope) handles the variety of cases
presented.

By renaming gnatmake, I checked that gnatmake
would look for the correctly named gcc with various versioned
and non-versioned target names over the gnatmake names of:

name ${target}-gnatmake
name ${target}-gnatmake3
name ${target}-gnatmake.378
name ${target}-gnatmake.exe
name ${target}-gnatmake.exe.3
name ${target}-gnatmake.exe.678
name ${target}-gnatmake.EXE.789
name ${target}-gnatmake.EXE;789

It seems to work ok now.

Comments appreciated.  Thanks to everyone who explained
the various filename formats.

--joel

Gabriel Paubert wrote:

> On Fri, Mar 19, 2004 at 06:17:46AM -0600, Joel Sherrill wrote:
> 
>>Looks to me that hist handling of VMS versioning is breaking all 
>>versioned hosts.  What is
>>the regular pattern for their versioned names?
> 
> 
> I believe something like the following (for grep-E or awk):
> 
> 	.*\..*\;[0-9]+
> 
> would work, but I'm not an expert at regular expressions, 
> resorting far too often to trial and error until it works
> for the specific case at hand.
> 
> So here are the rules (I'm still using VMS on a VAX
> a bit too much for my taste).
> 
> All filenames are of the form: 
> 
> 	name.type;version
> 
> after stripping the possible node::device:[directory]
> preceding them.
> 
> Name amd type are 1 to 38 characters, case is ignored, and
> very few characters are accepted outside of digits and letters. 
> Only one dot is allowed, between name and type. 
> 
> version is string of decimal digits, valid values
> for an existing file are 1 to 32767, but the file 
> system also interprets 0 as the latest version,  -1 
> as next to last, etc... 
> 
> Finally you can use either a semicolon or a dot
> between the name and the type when the type is specified.
> (To print a file without type on the screen, you have
> to type "TYPE FILE.", otherwise it will try to use a
> default extension for the command, .LIS in this case AFAIR)
> 
> In directory listings and file searches, the dot and the semicolon
> are always present, letters are always in uppercase. (But you can
> create a file called ".;1", with empty name and type fields, which 
> causes some funny things when an ftp program tries to transfer
> it to a Unix machine and strips the ;1 part).
> 
> 	Regards,
> 	Gabriel
> 
> P.S.: Just reading how to open a file on VMS with the medium 
> level calls (RMS) will make your head hurt. Trying to understand
> the low level calls will make you insane.
> 	
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: gcc 3.4 - gnatmake has wrong gcc name

[Paul Koning]

>>>>> "Joel" == Joel Sherrill <joel@OARcorp.com> writes:

 Joel> OK.. I think I have done it.  I have filed PR14665 with a patch
 Joel> which (I hope) handles the variety of cases presented.

 Joel> By renaming gnatmake, I checked that gnatmake would look for
 Joel> the correctly named gcc with various versioned and
 Joel> non-versioned target names over the gnatmake names of:

 Joel> name ${target}-gnatmake name ${target}-gnatmake3 name
 Joel> ${target}-gnatmake.378 name ${target}-gnatmake.exe name
 Joel> ${target}-gnatmake.exe.3 name ${target}-gnatmake.exe.678 name
 Joel> ${target}-gnatmake.EXE.789 name ${target}-gnatmake.EXE;789

 Joel> It seems to work ok now.

 Joel> Comments appreciated.  Thanks to everyone who explained the
 Joel> various filename formats.

Looks good.  With the versions number delimited by . rather than ;
you're all set for TOPS-20 too.  :-)

       paul

Re: gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

Paul Koning wrote:

>>>>>>"Joel" == Joel Sherrill <joel@OARcorp.com> writes:
>>>>>>            
>>>>>>
>
> Joel> OK.. I think I have done it.  I have filed PR14665 with a patch
> Joel> which (I hope) handles the variety of cases presented.
>
> Joel> By renaming gnatmake, I checked that gnatmake would look for
> Joel> the correctly named gcc with various versioned and
> Joel> non-versioned target names over the gnatmake names of:
>
> Joel> name ${target}-gnatmake name ${target}-gnatmake3 name
> Joel> ${target}-gnatmake.378 name ${target}-gnatmake.exe name
> Joel> ${target}-gnatmake.exe.3 name ${target}-gnatmake.exe.678 name
> Joel> ${target}-gnatmake.EXE.789 name ${target}-gnatmake.EXE;789
>
> Joel> It seems to work ok now.
>
> Joel> Comments appreciated.  Thanks to everyone who explained the
> Joel> various filename formats.
>
>Looks good.  With the versions number delimited by . rather than ;
>you're all set for TOPS-20 too.  :-)
>
>  
>
I'll leave TOPS-20 to you to test.  :)

>       paul
>
>  
>

Re: gcc 3.4 - gnatmake has wrong gcc name

[Paul Koning]

>>>>> "Arnaud" == Arnaud Charlet <charlet@ACT-Europe.FR> writes:

 >> So if I modified the code to do something like this, would it be
 >> OK algorithmically?
 >> 
 >> - strip off directory portion ("basename") - do equivalent of "sed
 >> -e 's/;[0-9]$/''

 Arnaud> version number can go above 9 I believe.

Correct -- version numbers are decimal numbers (up to 32767 I think,
but easiest is just to assume a sequence of digits).

    paul

Re: gcc 3.4 - gnatmake has wrong gcc name

[Douglas B Rupp]

>     I don't know. I believe it's ";version", e.g. GCC.EXE;2, but I'm no
>     VMS expert.

That's the VMS style, however gcc usually deals with the Unix style which is
gcc.exe.2   (dot vice semicolon).  Any fix must be able to handle both
styles.

Re: gcc 3.4 - gnatmake has wrong gcc name

[Arnaud Charlet]

> So if I modified the code to do something like this, would it
> be OK algorithmically?
> 
>    - strip off directory portion ("basename")
>    - do equivalent of "sed -e 's/;[0-9]$/''

version number can go above 9 I believe.

>    - do equivalent of "sed -e 's/.[eE][Xx][eE]$//'

Modulo the version issue above, that would be fine I think.

> I still view this as not as robust as my patch
> against 3.10p which used program_transform_name
> and put more the real names in sdefault.adb.

I haven't seen your patch, so can't comment, but if you have a fixed set
of tool names in sdefault.adb, I don't like this approach: I prefer
a general approach, that accomodates any new tool easily.

Anyway, I don't see the point in mentioning/complaining about your 3.10p
patch, I don't think you've ever submitted it for inclusion, so you
can't expect it to be included by some magic in more recent versions.

Arno

Re: gcc 3.4 - gnatmake has wrong gcc name

[Joel Sherrill]

Richard Kenner wrote:

>     I don't know. I believe it's ";version", e.g. GCC.EXE;2, but I'm no
>     VMS expert.
> 
> That's correct.

So if I modified the code to do something like this, would it
be OK algorithmically?

   - strip off directory portion ("basename")
   - do equivalent of "sed -e 's/;[0-9]$/''
   - do equivalent of "sed -e 's/.[eE][Xx][eE]$//'

I still view this as not as robust as my patch
against 3.10p which used program_transform_name
and put more the real names in sdefault.adb.

--joel

Re: gcc 3.4 - gnatmake has wrong gcc name

[Richard Kenner]

    I don't know. I believe it's ";version", e.g. GCC.EXE;2, but I'm no
    VMS expert.

That's correct.

Re: gcc 3.4 - gnatmake has wrong gcc name

[Richard Kenner]

    Richard (Kenner), do you remember this change ?
    date: 1996/11/24 16:17:57;  author: kenner;  state: Exp;  lines: +28 -21
    (Write_Program_Name): Replace previous change with code that will
     also strip off version number in VMS.

No, but the description makes it sound that we *were* still stripping it
off, but stripped the version number as well.  I suspect I didn't write
that change, but just checked it in.