I have the following program...
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.
JerryWell, 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:
Since my most recent post, and before I read this note from Niklas, Ifiles 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.
* 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
* 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.
On 2023-02-22 09:50, Jerry wrote: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.
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
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.* 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 youPlease see my previous post which I was writing at the time of your post. I think it answers your question.
been using the version of the compiler that gives you the error?
I would suggest deleting all compiler artifacts: .ali, .o[bj], executable, andI did that. Multiple times. No help.
trying again.
You could also try using gnatmake without a project file rather than gprbuild orI 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.
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.Wow. Good to know.
I'm sticking with V11[.3] until they're resolved. You might need to do the same.
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 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 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.
If you try to link with incompatible architectures, the linker willThat's useful info. So still not able to explain the mystery of why and when this problem appeared on my system.
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).
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 compileGoogle Groups clobbered my indentation. Here is the little "Y" and "N" table in another form:
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
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.
Compiles with no error (including the "with" clause) on my system, which is an
oldish one:
Jerry schrieb am Freitag, 24. Februar 2023 um 01:34:33 UTC+1:locations.
Compiles with either or both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" absent.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
Doesn't compile with both of "with GNAT.OS_Lib", "for Casing use "mixedcase"" present.
RThose three filenames are all lowercase.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 349 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 143:09:01 |
| Calls: | 7,613 |
| Calls today: | 1 |
| Files: | 12,790 |
| Messages: | 5,684,508 |