* Re: gcc 3.4 - gnatmake has wrong gcc name
@ 2004-03-19 14:52 Richard Kenner
2004-03-19 17:07 ` Joel Sherrill
2004-03-19 18:28 ` Douglas B Rupp
0 siblings, 2 replies; 22+ messages in thread
From: Richard Kenner @ 2004-03-19 14:52 UTC (permalink / raw)
To: charlet; +Cc: gcc
I don't know. I believe it's ";version", e.g. GCC.EXE;2, but I'm no
VMS expert.
That's correct.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 14:52 gcc 3.4 - gnatmake has wrong gcc name Richard Kenner
@ 2004-03-19 17:07 ` Joel Sherrill
2004-03-19 17:24 ` Arnaud Charlet
2004-03-19 18:28 ` Douglas B Rupp
1 sibling, 1 reply; 22+ messages in thread
From: Joel Sherrill @ 2004-03-19 17:07 UTC (permalink / raw)
To: Richard Kenner; +Cc: charlet, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 17:07 ` Joel Sherrill
@ 2004-03-19 17:24 ` Arnaud Charlet
2004-03-19 21:30 ` Paul Koning
0 siblings, 1 reply; 22+ messages in thread
From: Arnaud Charlet @ 2004-03-19 17:24 UTC (permalink / raw)
To: Joel Sherrill; +Cc: Richard Kenner, charlet, gcc
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 14:52 gcc 3.4 - gnatmake has wrong gcc name Richard Kenner
2004-03-19 17:07 ` Joel Sherrill
@ 2004-03-19 18:28 ` Douglas B Rupp
1 sibling, 0 replies; 22+ messages in thread
From: Douglas B Rupp @ 2004-03-19 18:28 UTC (permalink / raw)
To: Richard Kenner, charlet; +Cc: gcc
> 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 17:24 ` Arnaud Charlet
@ 2004-03-19 21:30 ` Paul Koning
0 siblings, 0 replies; 22+ messages in thread
From: Paul Koning @ 2004-03-19 21:30 UTC (permalink / raw)
To: charlet; +Cc: joel, kenner, gcc
>>>>> "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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-20 23:58 ` Paul Koning
@ 2004-03-21 18:03 ` Joel Sherrill
0 siblings, 0 replies; 22+ messages in thread
From: Joel Sherrill @ 2004-03-21 18:03 UTC (permalink / raw)
To: Paul Koning; +Cc: joel, paubert, charlet, wilson, gcc
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
>
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-20 23:08 ` Joel Sherrill
@ 2004-03-20 23:58 ` Paul Koning
2004-03-21 18:03 ` Joel Sherrill
0 siblings, 1 reply; 22+ messages in thread
From: Paul Koning @ 2004-03-20 23:58 UTC (permalink / raw)
To: joel; +Cc: paubert, joel.sherrill, charlet, wilson, gcc
>>>>> "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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 19:59 ` Gabriel Paubert
@ 2004-03-20 23:08 ` Joel Sherrill
2004-03-20 23:58 ` Paul Koning
0 siblings, 1 reply; 22+ messages in thread
From: Joel Sherrill @ 2004-03-20 23:08 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: Joel Sherrill, Arnaud Charlet, Jim Wilson, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 13:53 ` Joel Sherrill
2004-03-19 14:45 ` Arnaud Charlet
@ 2004-03-19 19:59 ` Gabriel Paubert
2004-03-20 23:08 ` Joel Sherrill
1 sibling, 1 reply; 22+ messages in thread
From: Gabriel Paubert @ 2004-03-19 19:59 UTC (permalink / raw)
To: Joel Sherrill; +Cc: Arnaud Charlet, Jim Wilson, gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 13:53 ` Joel Sherrill
@ 2004-03-19 14:45 ` Arnaud Charlet
2004-03-19 19:59 ` Gabriel Paubert
1 sibling, 0 replies; 22+ messages in thread
From: Arnaud Charlet @ 2004-03-19 14:45 UTC (permalink / raw)
To: Joel Sherrill; +Cc: Arnaud Charlet, Jim Wilson, gcc
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
@ 2004-03-19 14:18 Richard Kenner
0 siblings, 0 replies; 22+ messages in thread
From: Richard Kenner @ 2004-03-19 14:18 UTC (permalink / raw)
To: charlet; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 13:06 ` Arnaud Charlet
@ 2004-03-19 14:14 ` Joel Sherrill
0 siblings, 0 replies; 22+ messages in thread
From: Joel Sherrill @ 2004-03-19 14:14 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: Jim Wilson, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 11:19 ` Arnaud Charlet
2004-03-19 12:31 ` Jim Wilson
@ 2004-03-19 13:53 ` Joel Sherrill
2004-03-19 14:45 ` Arnaud Charlet
2004-03-19 19:59 ` Gabriel Paubert
1 sibling, 2 replies; 22+ messages in thread
From: Joel Sherrill @ 2004-03-19 13:53 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: Jim Wilson, gcc
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
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 12:31 ` Jim Wilson
@ 2004-03-19 13:06 ` Arnaud Charlet
2004-03-19 14:14 ` Joel Sherrill
0 siblings, 1 reply; 22+ messages in thread
From: Arnaud Charlet @ 2004-03-19 13:06 UTC (permalink / raw)
To: Jim Wilson; +Cc: Arnaud Charlet, Joel Sherrill, gcc
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-19 11:19 ` Arnaud Charlet
@ 2004-03-19 12:31 ` Jim Wilson
2004-03-19 13:06 ` Arnaud Charlet
2004-03-19 13:53 ` Joel Sherrill
1 sibling, 1 reply; 22+ messages in thread
From: Jim Wilson @ 2004-03-19 12:31 UTC (permalink / raw)
To: Arnaud Charlet; +Cc: Joel Sherrill, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-18 23:58 ` Joel Sherrill
@ 2004-03-19 11:19 ` Arnaud Charlet
2004-03-19 12:31 ` Jim Wilson
2004-03-19 13:53 ` Joel Sherrill
0 siblings, 2 replies; 22+ messages in thread
From: Arnaud Charlet @ 2004-03-19 11:19 UTC (permalink / raw)
To: Joel Sherrill; +Cc: Jim Wilson, gcc
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-18 20:07 ` Jim Wilson
@ 2004-03-18 23:58 ` Joel Sherrill
2004-03-19 11:19 ` Arnaud Charlet
0 siblings, 1 reply; 22+ messages in thread
From: Joel Sherrill @ 2004-03-18 23:58 UTC (permalink / raw)
To: Jim Wilson; +Cc: gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-18 14:24 ` Joel Sherrill
@ 2004-03-18 20:07 ` Jim Wilson
2004-03-18 23:58 ` Joel Sherrill
0 siblings, 1 reply; 22+ messages in thread
From: Jim Wilson @ 2004-03-18 20:07 UTC (permalink / raw)
To: Joel Sherrill; +Cc: gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-18 9:11 ` Jim Wilson
2004-03-18 9:37 ` Arnaud Charlet
@ 2004-03-18 14:24 ` Joel Sherrill
2004-03-18 20:07 ` Jim Wilson
1 sibling, 1 reply; 22+ messages in thread
From: Joel Sherrill @ 2004-03-18 14:24 UTC (permalink / raw)
To: Jim Wilson; +Cc: gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-18 9:11 ` Jim Wilson
@ 2004-03-18 9:37 ` Arnaud Charlet
2004-03-18 14:24 ` Joel Sherrill
1 sibling, 0 replies; 22+ messages in thread
From: Arnaud Charlet @ 2004-03-18 9:37 UTC (permalink / raw)
To: Jim Wilson; +Cc: Joel Sherrill, gcc
> I haven't tried to verify any of this with a build or debugger.
That's the correct explanation.
Arno
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc 3.4 - gnatmake has wrong gcc name
2004-03-17 15:43 Joel Sherrill
@ 2004-03-18 9:11 ` Jim Wilson
2004-03-18 9:37 ` Arnaud Charlet
2004-03-18 14:24 ` Joel Sherrill
0 siblings, 2 replies; 22+ messages in thread
From: Jim Wilson @ 2004-03-18 9:11 UTC (permalink / raw)
To: Joel Sherrill; +Cc: gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* gcc 3.4 - gnatmake has wrong gcc name
@ 2004-03-17 15:43 Joel Sherrill
2004-03-18 9:11 ` Jim Wilson
0 siblings, 1 reply; 22+ messages in thread
From: Joel Sherrill @ 2004-03-17 15:43 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-03-21 15:49 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-19 14:52 gcc 3.4 - gnatmake has wrong gcc name Richard Kenner
2004-03-19 17:07 ` Joel Sherrill
2004-03-19 17:24 ` Arnaud Charlet
2004-03-19 21:30 ` Paul Koning
2004-03-19 18:28 ` Douglas B Rupp
-- strict thread matches above, loose matches on Subject: below --
2004-03-19 14:18 Richard Kenner
2004-03-17 15:43 Joel Sherrill
2004-03-18 9:11 ` Jim Wilson
2004-03-18 9:37 ` Arnaud Charlet
2004-03-18 14:24 ` Joel Sherrill
2004-03-18 20:07 ` Jim Wilson
2004-03-18 23:58 ` Joel Sherrill
2004-03-19 11:19 ` Arnaud Charlet
2004-03-19 12:31 ` Jim Wilson
2004-03-19 13:06 ` Arnaud Charlet
2004-03-19 14:14 ` Joel Sherrill
2004-03-19 13:53 ` Joel Sherrill
2004-03-19 14:45 ` Arnaud Charlet
2004-03-19 19:59 ` Gabriel Paubert
2004-03-20 23:08 ` Joel Sherrill
2004-03-20 23:58 ` Paul Koning
2004-03-21 18:03 ` Joel Sherrill
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).