I have the following program...

with Common;
procedure Test_gnatS_Problem is
begin
null;
end Test_gnatS_Problem;

which is complied with GNAT 12.2.0 on MacOS 12.5. This minimal example is of course reduced from a useful program of mine. I am not including the gpr file here unless someone wants to see it. The output is...

Compile
[Ada] Test_gnatS_Problem.adb
[Ada] common.adb
[Ada] signal_processing.adb
[Ada] GSL_Thin.adb
GSL_Thin.adb:27:09: warning: unreachable code [enabled by default]
[Ada] numerical_recipes.adb
numerical_recipes.adb:209:13: warning: unreachable code [enabled by default]
[Ada] signals.adb
Bind
[gprbind] Test_gnatS_Problem.bexch
[Ada] Test_gnatS_Problem.ali
b__Test_gnatS_Problem.ads:582:30: error: external name duplicates name given at line 578
gprbind: compilation of binder generated file failed
gprbuild: unable to bind Test_gnatS_Problem.adb

I don't believe the warnings are germain. Here are a few lines from the referenced b__Test_gnatS_Problem.ads...

575 u00267 : constant Version_32 := 16#db4cf09e#;
576 pragma Export (C, u00267, "ada__strings__superboundedS");
577 u00268 : constant Version_32 := 16#b5988c27#;
578 pragma Export (C, u00268, "gnatS");
579 u00269 : constant Version_32 := 16#1a69b526#;
580 pragma Export (C, u00269, "gnat__os_libS");
581 u00270 : constant Version_32 := 16#b5988c27#;
582 pragma Export (C, u00270, "gnatS");
583 u00271 : constant Version_32 := 16#aebf1ee6#;
584 pragma Export (C, u00271, "system__byte_swappingS");

From the docs' listing of compiler switches...

-gnatS Print package Standard

Possibly relevant is that common and signal_processiung "with" eacb other and I have added a "limited with Signal_Processing" to common.ads.

I have no idea what is happening. I have compiled these sources zillions of times without seeing this problem. There is no reported problem with the source files, only the b_ file.

Jerry

On Monday, February 20, 2023 at 5:11:41 PM UTC-7, Jerry wrote:
> I have the following program...

Please let me summarize my problem: I have an Ada program which GNAT indicates has no errors but which it refuses to compile.

Jerry

On 2023-02-22 0:59, Jerry wrote:
> On Monday, February 20, 2023 at 5:11:41 PM UTC-7, Jerry wrote:
>> I have the following program...
>
> Please let me summarize my problem: I have an Ada program which GNAT
> indicates has no errors but which it refuses to compile.
>
> Jerry

Well, as you have shown only a part of the source code, it becomes a
guessing game for us others... but, since the compiler is pointing to an
error in a compiler-generated file, it seems likely that there is some
kind of compiler bug here. This bug seems to be activated by the
"limited with", if that is the main thing that you have changed since
the program last compiled successfully.

The compiler bug could be in the generation of the compiler-generated
file, or it could be a bug in checking the source code, with the effect
of not detecting or not reporting some error (illegality) in your source
code, which then somehow propagates within the compiler and makes the
compiler generate the faulty compiler-generated file.

You might report the bug to AdaCore, and/or try other versions of GNAT,
or othe Ada compilers. But the quickest way to continue is probably to
find a work-around, for example change the architecture so that you do
not need the "limited with" that seems to be triggering the problem.

On Tuesday, February 21, 2023 at 10:53:33 PM UTC-7, Niklas Holsti wrote:
> On 2023-02-22 0:59, Jerry wrote:
> > On Monday, February 20, 2023 at 5:11:41 PM UTC-7, Jerry wrote:
> >> I have the following program...
> >
> > Please let me summarize my problem: I have an Ada program which GNAT
> > indicates has no errors but which it refuses to compile.
> >
> > Jerry
> Well, as you have shown only a part of the source code, it becomes a
> guessing game for us others... but, since the compiler is pointing to an
> error in a compiler-generated file, it seems likely that there is some
> kind of compiler bug here. This bug seems to be activated by the
> "limited with", if that is the main thing that you have changed since
> the program last compiled successfully.
>
> The compiler bug could be in the generation of the compiler-generated
> file, or it could be a bug in checking the source code, with the effect
> of not detecting or not reporting some error (illegality) in your source
> code, which then somehow propagates within the compiler and makes the
> compiler generate the faulty compiler-generated file.
>
> You might report the bug to AdaCore, and/or try other versions of GNAT,
> or othe Ada compilers. But the quickest way to continue is probably to
> find a work-around, for example change the architecture so that you do
> not need the "limited with" that seems to be triggering the problem.

Since my most recent post, and before I read this note from Niklas, I
* Removed the circular dependency between packages common and signal_processing and consequently was able to remove the "limited with" clause.
* Reinstalled the compiler.
Neither of these had any effect--the problem remains.

To NIklas's note:
* I would be happy to supply all of the code but it is very long, thousands of lines across several packages.
* Yes, a possible compiler hiccup; but I have no clue or power to figure out what is wrong, since it is not pointing to my code.
* The "limited with" has been in the code for a few years; the problem that I am reporting has begun only about 2-3 days ago. At that point, I was adding a function to common.adb and common.ads; upon recompiling, the bug appeared. When I restored those files from backup, the problem remained. To be clear, the "limited with" has been present for a long time with successful compilation until 2-3 days ago.
* As far as I know, which is pretty far, the source code hasn't changed. As we all know, those are famous last words. :-| But the compiler isn't point to my code.
* As I wrote above, I re-wrote the code and removed the "limited with."

I am an individual researcher with no resources outside of bothering people such as those on this list, and at this point my work has come to a screeching halt.

Jerry

On 2023-02-22 09:50, Jerry wrote:
>
> Since my most recent post, and before I read this note from Niklas, I
> * Removed the circular dependency between packages common and signal_processing and consequently was able to remove the "limited with" clause.

> * The "limited with" has been in the code for a few years; the problem that I am reporting has begun only about 2-3 days ago. At that point, I was adding a function to common.adb and common.ads; upon recompiling, the bug appeared. When I restored those files from backup, the problem remained. To be clear, the "limited with" has been present for a long time with successful compilation until 2-3 days ago.

> * As far as I know, which is pretty far, the source code hasn't changed. As we all know, those are famous last words. :-| But the compiler isn't point to my code.

The first two statements seem to contradict the third. I will presume that you
have returned the code to the state that previously built successfully, and are
still getting the problem.

Something must have changed (unless GNAT 12 has a time bomb). How long have you
been using the version of the compiler that gives you the error?

I would suggest deleting all compiler artifacts: .ali, .o[bj], executable, and
trying again.

You could also try using gnatmake without a project file rather than gprbuild or
gnatmake with a project file to see if that has any effect.

GNAT 12 has significant known errors that prevent it from compiling legal code.
I'm sticking with V11[.3] until they're resolved. You might need to do the same.

--
Jeff Carter
“If it can't be expressed in figures,
it is not science--it is opinion.”
The Notebooks of Lazarus Long
210

On Wednesday, February 22, 2023 at 1:50:23 AM UTC-7, Jerry wrote:
> On Tuesday, February 21, 2023 at 10:53:33 PM UTC-7, Niklas Holsti wrote:

I just remembered something that I forgot to mention. In December 2022 I got a new MacBook Pro with an Apple M1 Pro CPU. Consequently, I installed Simon's ARM compiler from https://github.com/simonjwright/distributing-gcc/releases/tag/gcc-12.2.0-aarch64. When I restored common.adb and common.ads from backup, as I mentioned above after the problem appeared, I noticed that they were last edited in September 2022. Surely these files were recompiled with the new compiler in December 2022, right? Is it possible that I have been running old binaries for common.ads/b under the translator Rosetta 2 without realizing it? That the new compiler decided that these files didn't need to be recompiled because it saw the old x86-64 binaries ? Or that these files were compiled for the first time with the new compiler only 2-3 days ago, revealing a compiler bug? To be clear, I have been running successfully, since December 2022, other main programs that link to common and its dependencies—I had no need to edit common until 2-3 days ago.

On Wednesday, February 22, 2023 at 2:37:27 AM UTC-7, Jeffrey R.Carter wrote:
> On 2023-02-22 09:50, Jerry wrote:
> >
> > Since my most recent post, and before I read this note from Niklas, I
> > * Removed the circular dependency between packages common and signal_processing and consequently was able to remove the "limited with" clause.
> > * The "limited with" has been in the code for a few years; the problem that I am reporting has begun only about 2-3 days ago. At that point, I was adding a function to common.adb and common.ads; upon recompiling, the bug appeared. When I restored those files from backup, the problem remained. To be clear, the "limited with" has been present for a long time with successful compilation until 2-3 days ago.
>
> > * As far as I know, which is pretty far, the source code hasn't changed.. As we all know, those are famous last words. :-| But the compiler isn't point to my code.
> The first two statements seem to contradict the third. I will presume that you
> have returned the code to the state that previously built successfully, and are
> still getting the problem.
That is correct. Only after experiencing the problem with what I believe is the original code did I remove the limited with, and the problem remains without the limited with.
>
> Something must have changed (unless GNAT 12 has a time bomb). How long have you
> been using the version of the compiler that gives you the error?
Please see my previous post which I was writing at the time of your post. I think it answers your question.
>
> I would suggest deleting all compiler artifacts: .ali, .o[bj], executable, and
> trying again.
I did that. Multiple times. No help.
>
> You could also try using gnatmake without a project file rather than gprbuild or
> gnatmake with a project file to see if that has any effect.
I thought about that but I'm not sure how to do it. I guess the easiest way would be to make a new directory and put copies of the needed files in it so I don't have to make a bunch of weird switches.
>
> GNAT 12 has significant known errors that prevent it from compiling legal code.
Wow. Good to know.
> I'm sticking with V11[.3] until they're resolved. You might need to do the same.

Not sure what the Mac/ARM situation is with V11.
Jerry

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> writes:

> You could also try using gnatmake without a project file rather than
> gprbuild or gnatmake with a project file to see if that has any
> effect.

If you give gnatmake a project file and it finds gprbuild on the PATH,
it'll delegate to gprbuild.

I deleted lines from common.adb and common.ads piecemeal until I arrived at this MWE:

with Common;
procedure Test_gnatS_Problem is
begin
null;
end Test_gnatS_Problem;

package body Common is
procedure Dummy is
begin
null;
end Dummy;
end Common;

with GNAT.OS_Lib; -- Error disappears when this line is removed.
package Common is
procedure Dummy;
end Common;

Surely this is enough for someone to work with in fixing this problem.

Jerry

On 2023-02-23 8:34, Jerry wrote:
> I deleted lines from common.adb and common.ads piecemeal until I arrived at this MWE:
>
> with Common;
> procedure Test_gnatS_Problem is
> begin
> null;
> end Test_gnatS_Problem;
>
> package body Common is
> procedure Dummy is
> begin
> null;
> end Dummy;
> end Common;
>
> with GNAT.OS_Lib; -- Error disappears when this line is removed.
> package Common is
> procedure Dummy;
> end Common;
>
> Surely this is enough for someone to work with in fixing this problem.
>
> Jerry

Compiles with no error (including the "with" clause) on my system, which
is an oldish one:

GNAT Community 2019 (20190517-83)
MacOS Mojave

Jerry <list_email@icloud.com> writes:

> On Wednesday, February 22, 2023 at 1:50:23 AM UTC-7, Jerry wrote:
>> On Tuesday, February 21, 2023 at 10:53:33 PM UTC-7, Niklas Holsti wrote:
>
> I just remembered something that I forgot to mention. In December 2022
> I got a new MacBook Pro with an Apple M1 Pro CPU. Consequently, I
> installed Simon's ARM compiler from
> https://github.com/simonjwright/distributing-gcc/releases/tag/gcc-12.2.0-aarch64.
> When I restored common.adb and common.ads from backup, as I mentioned
> above after the problem appeared, I noticed that they were last edited
> in September 2022. Surely these files were recompiled with the new
> compiler in December 2022, right? Is it possible that I have been
> running old binaries for common.ads/b under the translator Rosetta 2
> without realizing it? That the new compiler decided that these files
> didn't need to be recompiled because it saw the old x86-64 binaries ?
> Or that these files were compiled for the first time with the new
> compiler only 2-3 days ago, revealing a compiler bug? To be clear, I
> have been running successfully, since December 2022, other main
> programs that link to common and its dependencies—I had no need to
> edit common until 2-3 days ago.

Building your downstream demo on M1 Mac Mini with gcc-12.2.0 (an x86_64
compiler running under Rosetta),

$ /opt/gcc-12.2.0/bin/gnatmake test_gnats_problem.adb
gcc -c test_gnats_problem.adb
gcc -c common.adb
gnatbind -x test_gnats_problem.ali
gnatlink test_gnats_problem.ali
$ file common.o
common.o: Mach-O 64-bit object x86_64

Building with the aarch64 version of the same compiler,

$ /opt/gcc-12.2.0-aarch64/bin/gnatmake test_gnats_problem
gcc -c test_gnats_problem.adb
gcc -c common.adb
gnatbind -x test_gnats_problem.ali
gnatlink test_gnats_problem.ali
$ file common.o
common.o: Mach-O 64-bit object arm64

and then rebuilding for x86_64,

$ /opt/gcc-12.2.0/bin/gnatmake test_gnats_problem.adb
gcc -c test_gnats_problem.adb
gcc -c common.adb
gnatbind -x test_gnats_problem.ali
gnatlink test_gnats_problem.ali
$ file common.o
common.o: Mach-O 64-bit object x86_64

so the compiler recognises the change and recompiles (I think this is
because the date of g-os_lib.ads has changed, even though the checksum
hasn't).

The situation might be different if you compile with 'gnatmake -m'.

If you try to link with incompatible architectures, the linker will
refuse (as I just found when rebuilding alr using an x86_64 compiler,
when the previous build was with aarch64; in that case, the source that
led to the problem was unchanged, down to the file dates).

On Thursday, February 23, 2023 at 6:16:19 AM UTC-7, Simon Wright wrote:

> If you try to link with incompatible architectures, the linker will
> refuse (as I just found when rebuilding alr using an x86_64 compiler,
> when the previous build was with aarch64; in that case, the source that
> led to the problem was unchanged, down to the file dates).
That's useful info. So still not able to explain the mystery of why and when this problem appeared on my system.

Jerry

More info.

* I reduced the MWE to not referencing Common package—it’s now only a main program.
* I changed file name and program name to lower case.
* I stripped down my .gpr file to nearly bare minimum.
* Observe presence or absence of “with GNAT.OS_Lib” in main and “for Casing use "mixedcase”” in .gpr.
Results summary:
* Compiling with gnatmake works always.
* Compiling with gprbuild shows dependence between presence or absence of the two lines. Details follow.
* Recall that I am on MacOS. I have had to use the “mixedcase” flag to mitigate other problems in the past.
* My current workaround is to not use GNAT.OS_Lib which is sub-optimal.

Main program (Lower-case file and procedure names), test_gnats_problem.adb

-- with GNAT.OS_Lib; -- <<<<<
procedure test_gnats_problem is
begin
null;
end test_gnats_problem;

==========================================================
Build command, gprbuild:

gprbuild -p /Users/jb/Documents/Programs/Ada/Code/My_Projects/TextMate_Sampling/build.gpr

GPR file, build.gpr:

project Build is
for Source_Dirs use
("/Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes");
for Object_Dir use "build-normal";
for Exec_Dir use "product-normal";
for Main use ("test_gnats_problem.adb");

package Builder is
for Default_Switches ("Ada") use ("-gnat12");
for Executable ("test_gnats_problem.adb") use "run";
end Builder;

package Naming is
-- for Casing use "mixedcase"; -- <<<<<
end Naming;
end Build;

Results: Y Compiles, N Does not compile

for Casing use "mixedcase" -- for Casing use "mixedcase"
with GNAT.OS_Lib N Y
-- with GNAT.OS_Lib Y Y

gprbuild Output:

Compile
[Ada] test_gnats_problem.adb
Bind
[gprbind] test_gnats_problem.bexch
[Ada] test_gnats_problem.ali
b__test_gnats_problem.ads:144:30: error: external name duplicates name given at line 50
gprbind: compilation of binder generated file failed
gprbuild: unable to bind test_gnats_problem.adb

==========================================================
Build command, gnatmake, with output.
Produces the same result (compiles) with or without “with GNAT.OS_Lib”

$ gnatmake /Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes/test_gnats_problem.adb
gcc -c -I/Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes/ -I- /Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes/test_gnats_problem.adb
gnatbind -x test_gnats_problem.ali
gnatlink test_gnats_problem.ali

On Thursday, February 23, 2023 at 5:28:48 PM UTC-7, Jerry wrote:
> More info.
>
> * I reduced the MWE to not referencing Common package—it’s now only a main program.
> * I changed file name and program name to lower case.
> * I stripped down my .gpr file to nearly bare minimum.
> * Observe presence or absence of “with GNAT.OS_Lib” in main and “for Casing use "mixedcase”” in .gpr.
> Results summary:
> * Compiling with gnatmake works always.
> * Compiling with gprbuild shows dependence between presence or absence of the two lines. Details follow.
> * Recall that I am on MacOS. I have had to use the “mixedcase” flag to mitigate other problems in the past.
> * My current workaround is to not use GNAT.OS_Lib which is sub-optimal.
>
>
> Main program (Lower-case file and procedure names), test_gnats_problem.adb
>
> -- with GNAT.OS_Lib; -- <<<<<
> procedure test_gnats_problem is
> begin
> null;
> end test_gnats_problem;
>
> ===========================================================
>
> Build command, gprbuild:
>
> gprbuild -p /Users/jb/Documents/Programs/Ada/Code/My_Projects/TextMate_Sampling/build.gpr
>
> GPR file, build.gpr:
>
> project Build is
> for Source_Dirs use
> ("/Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes");
> for Object_Dir use "build-normal";
> for Exec_Dir use "product-normal";
>
> for Main use ("test_gnats_problem.adb");
>
> package Builder is
> for Default_Switches ("Ada") use ("-gnat12");
> for Executable ("test_gnats_problem.adb") use "run";
> end Builder;
>
> package Naming is
> -- for Casing use "mixedcase"; -- <<<<<
> end Naming;
> end Build;
>
>
> Results: Y Compiles, N Does not compile
>
> for Casing use "mixedcase" -- for Casing use "mixedcase"
> with GNAT.OS_Lib N Y
> -- with GNAT.OS_Lib Y Y
>
> gprbuild Output:
>
> Compile
> [Ada] test_gnats_problem.adb
> Bind
> [gprbind] test_gnats_problem.bexch
> [Ada] test_gnats_problem.ali
> b__test_gnats_problem.ads:144:30: error: external name duplicates name given at line 50
> gprbind: compilation of binder generated file failed
> gprbuild: unable to bind test_gnats_problem.adb
>
> ===========================================================
>
> Build command, gnatmake, with output.
> Produces the same result (compiles) with or without “with GNAT.OS_Lib”
>
> $ gnatmake /Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes/test_gnats_problem.adb
> gcc -c -I/Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes/ -I- /Users/jb/Documents/Programs/Ada/Code/My_Code/Examples_and_Snippets_and_Notes/test_gnats_problem.adb
> gnatbind -x test_gnats_problem.ali
> gnatlink test_gnats_problem.ali
Google Groups clobbered my indentation. Here is the little "Y" and "N" table in another form:

Compiles with either or both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" absent.
Doesn't compile with both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" present.

Jerry

Jerry schrieb am Freitag, 24. Februar 2023 um 01:34:33 UTC+1:

> Compiles with either or both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" absent.
> Doesn't compile with both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" present.

look for the casing of gnat.ads, g-os_lib.ads and g-os_lib.adb on your system. The lines 578 and 582 refer to the spec of gnat, hence the capital S in gnatS. It seems to me to be included twice because of the mixed casing, perhaps from different locations.

R

On 2023-02-23 13:57, Niklas Holsti wrote:
>
> Compiles with no error (including the "with" clause) on my system, which is an
> oldish one:

And on Linus with GNAT 11.3.

--
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

On Friday, February 24, 2023 at 1:07:08 AM UTC-7, R R wrote:
> Jerry schrieb am Freitag, 24. Februar 2023 um 01:34:33 UTC+1:
>
> > Compiles with either or both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" absent.
> > Doesn't compile with both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" present.
> look for the casing of gnat.ads, g-os_lib.ads and g-os_lib.adb on your system. The lines 578 and 582 refer to the spec of gnat, hence the capital S in gnatS. It seems to me to be included twice because of the mixed casing, perhaps from different locations.
>
> R
Those three filenames are all lowercase.

Jerry