Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 864
Product:  
Component:  
Status: RESOLVED
Resolution: FIXED
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: benoit.hudson@gmail.com
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
program-transform-name.diff patch patch 2009-07-26 20:37 1.62 KB Edit | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 864 depends on: Show dependency tree
Show dependency graph
Bug 864 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: 2006-01-08 05:20 Opened: 2000-11-21 19:36
I configured in directory 
  gcc-objects
using
  ../gcc-2.95.2/configure --prefix=${HOME}/experimental  \
 --program-suffix=-2.95.2 --disable-nls    \
 --with-gnu-ld --with-gnu-as
(as config.status confirms).

Directory ${HOME}/experimental previously contained only
binutils-2.10.1.

After make install, I find that I have the gcc executables
installed as c++, c++filt, cpp, and so on.

Is it, like most things, fixed in CVS?

Release:
2.95.2

Environment:
sparc-sun-solaris2.6

------- Comment #1 From Joseph S. Myers 2001-11-05 02:53 -------
State-Changed-From-To: open->analyzed
State-Changed-Why: A patch is being worked on:
    http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00129.html
    (but note that support for this configure option is not currently
    a documented feature).
    
    I've closed the following PRs which describe the same
    problem as this one: 1946, 3225, 3286, 3806, 4073, 4621.

------- Comment #2 From steven.bosscher@usafa.af.mil 2002-11-19 08:51 -------
From: Bosscher Steven Civ USAFA/DFAN <Steven.Bosscher@usafa.af.mil>
To: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
        "'jsm28@cam.ac.uk'"<jsm28@cam.ac.uk>,
        "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
        "'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>,
        "'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>
Cc:  
Subject: Re: other/864: --program-suffix is ignored
Date: Tue, 19 Nov 2002 08:51:28 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
 r=864
 
 Works for me with GCC 3.2 and later.
 
 So is this bug fixed and should the PR be closed?
 
 Greetz
 Steven


------- Comment #3 From steven.bosscher@usafa.af.mil 2002-11-19 15:32 -------
From: Bosscher Steven Civ USAFA/DFAN <Steven.Bosscher@usafa.af.mil>
To: "'Joseph S. Myers'" <jsm28@cam.ac.uk>,
        Bosscher Steven Civ USAFA/DFAN <Steven.Bosscher@usafa.af.mil>
Cc: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
        "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>
Subject: RE: other/864: --program-suffix is ignored
Date: Tue, 19 Nov 2002 15:32:50 -0700

 Right, Ada is the only language I did not test...
 
 -----Original Message-----
 From: Joseph S. Myers [mailto:jsm28@cam.ac.uk] 
 Sent: Tuesday, November 19, 2002 3:14 PM
 To: Bosscher Steven Civ USAFA/DFAN
 Cc: 'gcc-gnats@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org'
 Subject: Re: other/864: --program-suffix is ignored
 
 On Tue, 19 Nov 2002, Bosscher Steven Civ USAFA/DFAN wrote:
 
 >
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
 > r=864
 > 
 > Works for me with GCC 3.2 and later.
 > 
 > So is this bug fixed and should the PR be closed?
 
 Do the Ada program names get transformed properly?  The manual says not.  
 This should be closed once fixed properly (i.e., _all_ installed programs
 are transformed in the defined way).
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk

------- Comment #4 From Joseph S. Myers 2002-11-19 22:13 -------
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Bosscher Steven Civ USAFA/DFAN <Steven.Bosscher@usafa.af.mil>
Cc: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>, 
    "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>
Subject: Re: other/864: --program-suffix is ignored
Date: Tue, 19 Nov 2002 22:13:55 +0000 (GMT)

 On Tue, 19 Nov 2002, Bosscher Steven Civ USAFA/DFAN wrote:
 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
 > r=864
 > 
 > Works for me with GCC 3.2 and later.
 > 
 > So is this bug fixed and should the PR be closed?
 
 Do the Ada program names get transformed properly?  The manual says not.  
 This should be closed once fixed properly (i.e., _all_ installed programs
 are transformed in the defined way).
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 


------- Comment #5 From Andrew Pinski 2003-07-24 14:19 -------
*** Bug 6725 has been marked as a duplicate of this bug. ***

------- Comment #6 From Ludovic Brenta 2004-03-16 17:05 -------
The file gcc/ada/osint.adb contains code in function Program_Name (around line 
1463) which prevents renaming the executables if the program prefix or suffix 
contains a hyphen (-).

This code examines the name of the gnatmake executable and, if it contains a 
hyphen, it flags the compiler as being a cross-compiler, and changes the name
of the gcc compiler to use the same prefix.  For example, I tried renaming
gnatmake to gnatmake-3.3 and gcc to gcc-3.3, and got this:

make diners GNATMAKE=gnatmake-3.3
gnatmake-3.3 diners -cargs -O2
gnatmake-gcc-3.3 -c -O2 diners.adb                    [1]
gnatmake-3: error, unable to locate gnatmake-gcc-3.3  [2]
make: *** [diners] Error 4

The problem at line [1] is described above.

At line [2], GNAT also changed "gnatmake-3.3" to "gnatmake-3".  This
is because it assumes that everything after the last "." in the file
name is an extension, and removes it.  This is valid only on some hosts.
See osint.adb around line 797 in procedure Find_Program_Name.

-- 
Ludovic Brenta.

------- Comment #7 From Arnaud Charlet 2008-05-12 23:42 -------
*** Bug 29127 has been marked as a duplicate of this bug. ***

------- Comment #8 From Arnaud Charlet 2008-05-13 13:39 -------
*** Bug 29127 has been marked as a duplicate of this bug. ***

------- Comment #9 From Arnaud Charlet 2008-05-13 13:40 -------
Assigning to myself.

------- Comment #10 From Arnaud Charlet 2008-05-29 08:56 -------
Subject: Bug 864

Author: charlet
Date: Thu May 29 08:56:01 2008
New Revision: 136149

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136149
Log:
        PR ada/864
        * osint.ads, osint.adb (Program_Name): New parameter "Prog" to
        allow recognition of program suffix in addition to prefix.

        * gnatchop.adb (Locate_Executable): Add support for prefix.

        * make.adb, gnatcmd.adb, gnatlink.adb, prj-makr.adb,
        mlib-utl.adb: Adjust calls to Program_Name.

Modified:
    trunk/gcc/ada/gnatchop.adb
    trunk/gcc/ada/gnatcmd.adb
    trunk/gcc/ada/gnatlink.adb
    trunk/gcc/ada/make.adb
    trunk/gcc/ada/mlib-utl.adb
    trunk/gcc/ada/osint.adb
    trunk/gcc/ada/osint.ads
    trunk/gcc/ada/prj-makr.adb

------- Comment #11 From Arnaud Charlet 2008-05-29 08:59 -------
Fixed.

------- Comment #12 From Arnaud Charlet 2008-05-29 09:04 -------
*** Bug 33857 has been marked as a duplicate of this bug. ***

------- Comment #13 From Dave Korn 2009-07-26 14:26 -------
  Broken again on HEAD :-(

  Configured with --program-suffix=-4, bootstrapped, and installed into a new
$prefix that I then placed at the front of $PATH.

  None of the newly built gnat* executables had the --program-suffix appended.

  When trying to run the testsuite, host_gnatmake invokes plain unadorned
'gnatmake', which finds the newly-installed one in $prefix.  That attempts to
invoke plain unadorned 'gcc' unfortunately, which is the distro compiler
installed in /usr/bin, and not the newly installed $prefix/bin/gcc-4, resulting
in the following error:

> + host_gnatmake -gnatws macrosub.adb
> 
> GNATMAKE 4.5.0 20090707 (experimental)
> Copyright (C) 1995-2009, Free Software Foundation, Inc.
>   "macrosub.ali" being checked ...
>   -> "macrosub.ali" missing.
> gcc -c -gnatV -gnatws macrosub.adb
> gnat1: invalid switch: -gnatea
> End of compilation

I tried hacking host_gnatmake and host_gnatchop to pass --GCC=gcc-4, but that
only got me a little way further:

> + host_gnatmake -gnatws macrosub.adb
> 
> GNATMAKE 4.5.0 20090707 (experimental)
> Copyright (C) 1995-2009, Free Software Foundation, Inc.
>   "macrosub.ali" being checked ...
>   -> "macrosub.ali" missing.
> gcc-4 -c -gnatws macrosub.adb
>   "defs.ali" being checked ...
>   -> "defs.ali" missing.
> gcc-4 -c -gnatws defs.ads
>   "getsubs.ali" being checked ...
>   -> "getsubs.ali" missing.
> gcc-4 -c -gnatws getsubs.adb
>   "parsemac.ali" being checked ...
>   -> "parsemac.ali" missing.
> gcc-4 -c -gnatws parsemac.adb
>   "text_io.ali" is a read-only library
> End of compilation
> gnatbind -x macrosub.ali
> gnatlink macrosub.ali
> b~macrosub.o:b~macrosub.adb:(.eh_frame+0x11): undefined reference to `___gnat_eh
> _personality'
> collect2: ld returned 1 exit status
> gnatlink: error when calling /usr/bin/gcc.exe
> gnatmake: *** link failed.

... the problem being that yet again the unsuffixed system compiler has been
invoked, and it's using the system runtime libs rather than the ones that go
with the newly-built compiler in $prefix (and which happen to be ABI
incompatible because they use ZCX instead of SJLJ).

  Should gnatmake have passed down the --GCC= option to gnatbind and gnatlink?

------- Comment #14 From Richard Guenther 2009-07-26 19:53 -------
>  None of the newly built gnat* executables had the --program-suffix appended.

that never happened.  Distros carry patches for this since ages.

------- Comment #15 From Arnaud Charlet 2009-07-26 20:33 -------
Right, my change fixed gnatmake so that it would call the proper gcc (based on
the
previous comments on this PR), but Makefiles have never supported 
--program-suffix, so that's not even a regression.

Feel free to submit a patch, I think it would be fair for someone with an
interest in this feature to do so, since Ada maintainers have no specific
interest in this option, and this is really a Makefile/infrastructure issue
at this stage rather than an Ada issue (I did fix the Ada specific issue
reported
in gnatmake, and this feature is still working AFAIK).

------- Comment #16 From Richard Guenther 2009-07-26 20:37 -------
Created an attachment (id=18256) [edit]
patch

FYI this is what SUSE carries along.

------- Comment #17 From Dave Korn 2009-07-26 20:39 -------
(In reply to comment #15)
> Right, my change fixed gnatmake so that it would call the proper gcc (based on
> the
> previous comments on this PR), but Makefiles have never supported 
> --program-suffix, so that's not even a regression.

  Uh, you both focussed on the line where I mentioned in passing that the gnat
executables don't get suffixed, and missed the actual bug report: it does *not*
call the proper GCC.  Regardless of whether gnatmake itself gets a suffix or
not, it should have invoked "gcc-4", not "gcc", shouldn't it?

------- Comment #18 From rguenther@suse.de 2009-07-26 20:44 -------
Subject: Re:  --program-suffix is ignored (for ada)

On Sun, 26 Jul 2009, davek at gcc dot gnu dot org wrote:

> ------- Comment #17 from davek at gcc dot gnu dot org  2009-07-26 20:39 -------
> (In reply to comment #15)
> > Right, my change fixed gnatmake so that it would call the proper gcc (based on
> > the
> > previous comments on this PR), but Makefiles have never supported 
> > --program-suffix, so that's not even a regression.
> 
>   Uh, you both focussed on the line where I mentioned in passing that the gnat
> executables don't get suffixed, and missed the actual bug report: it does *not*
> call the proper GCC.  Regardless of whether gnatmake itself gets a suffix or
> not, it should have invoked "gcc-4", not "gcc", shouldn't it?

No, the support that was implemented is that the suffix of gnatmake
is the one that gcc gets suffixed with.

Richard.

------- Comment #19 From Dave Korn 2009-07-26 20:57 -------
(In reply to comment #18)

> No, the support that was implemented is that the suffix of gnatmake
> is the one that gcc gets suffixed with.

Ah ok, I see.  Then it's working as designed.  Sorry for the noise in your
inbox.    Judging from the way your patch only changes the names at install
time, I expect that if I manually rename the files after they've been
installed, they'll also notice their new suffixes and it should all work ok. 
Bug reclosed.

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug