Bug 79724 - GNAT tools do not respect --program-suffix and --program-prefix
Summary: GNAT tools do not respect --program-suffix and --program-prefix
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: ada (show other bugs)
Version: 6.2.1
: P3 normal
Target Milestone: 12.0
Assignee: Arnaud Charlet
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2017-02-27 12:56 UTC by Matthias Klose
Modified: 2022-04-06 15:24 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-12-23 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2017-02-27 12:56:54 UTC
currently --program-suffix and --program-prefix are not respected by the various ada tools.  They might be installed correctly with the configured prefix and suffix, but internally tools are called without prefix and suffix (e.g. gnatmake still calls <prefix>/bin/gcc, which might point to another version of gcc not having ada installed).

Debian/Ubuntu had a patch to resolve this, and to call the tools with the suffix name, however for some occasions it would append the suffix twice (any hint what is wrong with the patch would be appreciated).

The current patch:
https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-7/debian/patches/ada-gcc-name.diff?revision=9242&view=markup

Problems caused with this patch: https://bugs.debian.org/814978

"""
Due to the Debian patch ada-gcc-name.diff the name of gcc becomes gcc-5-5
instead of gcc-5. This is easily shown with:
/usr/bin/gnatchop -v fc51b00.a
where fcb51b.a is located at src/gcc/testsuite/ada/acats/support/
(same when run as a shell command)

GNATCHOP 5.3.1
Copyright (C) 1998-2015, Free Software Foundation, Inc.
gcc-5-5: installation problem, executable not found
no source files written

However, issuing the command directly via path works:
gnatchop -v fc51b00.a
GNATCHOP 5.3.1
Copyright (C) 1998-2015, Free Software Foundation, Inc.
/usr/bin/gcc-5 -c -x ada -gnats -gnatu fc51b00.a
splitting fc51b00.a into:
   fc51b00.ads
with:
which gnatchop
/usr/bin/gnatchop
"""

So two issues: what causes the duplication of the suffix, and how to generalize the tool names to include the prefix and the suffix?
Comment 1 Francois-Xavier Coudert 2021-12-23 09:56:07 UTC
Confirmed. This is blocking Ada integration into Homebrew: https://github.com/Homebrew/homebrew-core/pull/77641

We configure GCC with:
configure --prefix=/tmp/irun --enable-languages=all --program-suffix=-11

This leads to the installation of suffixed gnat tools:

meau /tmp/irun $ ls bin/gnat*
bin/gnat-11      bin/gnatchop-11  bin/gnatkr-11    bin/gnatls-11    bin/gnatname-11
bin/gnatbind-11  bin/gnatclean-11 bin/gnatlink-11  bin/gnatmake-11  bin/gnatprep-11

But they're not usable:

meau /tmp/irun $ gnatmake-11 hello.adb
gcc -c hello.adb
clang: error: unknown argument: '-gnatea'
clang: error: unknown argument: '-gnatez'
gnatmake-11: "hello.adb" compilation error

because gnatmake-11 is calling the unsuffixed `gcc`, which does not support Ada.
(On macOS, this system compiler is a wrapper to clang.)

Even if I try to add some options to gnatmake, it will still somehow fail, because the relevant options are not passed down to gnatlink:

meau /tmp/irun $ gnatmake-11 hello.adb --GCC=gcc-11 --GNATBIND=gnatbind-11 --GNATLINK=gnatlink-11
gcc-11 -c hello.adb
gnatbind-11 -x hello.ali
gnatlink-11 hello.ali
clang: error: unknown argument: '-gnatA'
clang: error: unknown argument: '-gnatWb'
clang: error: unknown argument: '-gnatiw'
clang: error: unknown argument: '-gnatws'
gnatmake-11: *** link failed.
Comment 2 Francois-Xavier Coudert 2021-12-23 10:18:48 UTC
It's puzzling, because although I've never read any Ada code, I can see there is some logic in place that should deal with it. In make.adb there is:

   Gcc      : String_Access := Program_Name ("gcc", "gnatmake");
   Gnatbind : String_Access := Program_Name ("gnatbind", "gnatmake");
   Gnatlink : String_Access := Program_Name ("gnatlink", "gnatmake");

and in osint.adb the function Program_Name has some logic to find prefix and suffix:

      --  Find the target prefix if any, for the cross compilation case.
      --  For instance in "powerpc-elf-gcc" the target prefix is
      --  "powerpc-elf-"
      --  Ditto for suffix, e.g. in "gcc-4.1", the suffix is "-4.1"

and it uses them to return the program that is going to be used:

      --  Create the new program name

      return new String'
        (Name_Buffer (Start_Of_Prefix .. End_Of_Prefix)
         & Nam
         & Name_Buffer (Start_Of_Suffix .. Name_Len));

I tried to debug this by sticking some Ada.Text_IO.Put_Line calls, but either I'm doing it wrong, or it's never actually called.
Comment 3 Eric Gallager 2021-12-23 13:28:14 UTC
MacPorts also configures with --program-suffix so if we ever wanted to add ada support there, this would block that, too.
Comment 4 Francois-Xavier Coudert 2021-12-23 13:52:02 UTC
The current situation is the result of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
Comment 20 by Dave Korn (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=864#c20) is spot on:

> ... means that it only recognizes a suffix if there is also a prefix, i.e. it only
> works for cross-compilers.  The documentation suggests this is deliberate:
> [...]
> but why?  The native behaviour is wrong and it seems incorrect to me that
> it should have different semantics from the cross-compiler case.

As far as I can see, this comment from 2011 was never addressed, and the bug was closed. This is what is biting us, this logic needs to be improved.

The simplest patch is to detect suffix in all cases, as far as I can see one only needs to remove the test:


diff --git a/gcc/ada/osint.adb b/gcc/ada/osint.adb
index cf39128fb7b..9a578a62273 100644
--- a/gcc/ada/osint.adb
+++ b/gcc/ada/osint.adb
@@ -2286,9 +2286,7 @@ package body Osint is
          end if;
       end loop;
 
-      if End_Of_Prefix > 1 then
-         Start_Of_Suffix := End_Of_Prefix + Prog'Length + 1;
-      end if;
+      Start_Of_Suffix := End_Of_Prefix + Prog'Length + 1;
 
       --  Create the new program name
 

And with this patch I get the expected result:

$ gnatmake-11 hello.adb     
gcc-11 -c hello.adb
gnatbind-11 -x hello.ali
gnatlink-11 hello.ali
Comment 5 Arnaud Charlet 2022-01-03 10:49:35 UTC
Thanks for the investigation. What's tricky and why things got stuck last time is the complexity of testing all the possible combinations (prefix, or suffix, or both).
Can you in particular check that your proposed patch isn't breaking the use of a prefix with no suffix (e.g. i686-elf-gcc) and check the behavior when using
both a prefix and a suffix (e.g. i686-elf-gcc-4.1)?
Comment 6 Francois-Xavier Coudert 2022-01-04 14:24:38 UTC
I checked the patch on all 4 possible cases with/without prefix and with/without suffix. I confirm they all work as expected, with the patch. In addition, I think the logic of the code is sane (although I have never written any Ada in my life).

It would really help if we could get this in, it would enable us to ship Ada as part of GCC in Homebrew.
Comment 7 Arnaud Charlet 2022-01-04 15:25:49 UTC
Understood, I'll work on it then, thanks for your help!
Comment 8 GCC Commits 2022-01-11 13:27:41 UTC
The master branch has been updated by Pierre-Marie de Rodat <pmderodat@gcc.gnu.org>:

https://gcc.gnu.org/g:7aa3800216ea991050ec904a28c628cd7799021b

commit r12-6459-g7aa3800216ea991050ec904a28c628cd7799021b
Author: Arnaud Charlet <charlet@adacore.com>
Date:   Mon Jan 3 10:51:07 2022 +0000

    [Ada] PR ada/79724
    
    gcc/ada/
    
            PR ada/79724
            * osint.adb (Program_Name): Fix handling of suffixes.
Comment 9 Arnaud Charlet 2022-01-11 13:30:56 UTC
Should now be fully fixed!
Comment 10 Nicolas Boulenguez 2022-04-06 15:24:58 UTC
Hello.

I suggest that Homebrew adopt a solution tested for years by Debian:
* install the executables as TARGET-gcc-VERSION
* add symbolic links if necessary (gcc, gcc-VERSION, TARGET-gcc)
* apply the patch provided here over 3 years ago
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87777
  This URL always links to latest rebase:
  https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/ada-gcc-name.diff

Until the assumptions are made explicit, the upstream code trying to guess the name of the gcc executable will probably keep changing, as it has for at least ten years. I have counted at least 6 similar bugs, and that’s only on Debian. 

This leads to duplicate efforts. For example, the diagnostic of this specific index error is included in the patch above.