* Weird error emanating from GNAT binder: duplicat "gnatS" @ 2023-02-21 0:11 Jerry 2023-02-21 22:59 ` Jerry 0 siblings, 1 reply; 17+ messages in thread From: Jerry @ 2023-02-21 0:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-21 0:11 Weird error emanating from GNAT binder: duplicat "gnatS" Jerry @ 2023-02-21 22:59 ` Jerry 2023-02-22 5:53 ` Niklas Holsti 0 siblings, 1 reply; 17+ messages in thread From: Jerry @ 2023-02-21 22:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-21 22:59 ` Jerry @ 2023-02-22 5:53 ` Niklas Holsti 2023-02-22 8:50 ` Jerry 0 siblings, 1 reply; 17+ messages in thread From: Niklas Holsti @ 2023-02-22 5:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-22 5:53 ` Niklas Holsti @ 2023-02-22 8:50 ` Jerry 2023-02-22 9:37 ` Jeffrey R.Carter 2023-02-22 9:39 ` Jerry 0 siblings, 2 replies; 17+ messages in thread From: Jerry @ 2023-02-22 8:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-22 8:50 ` Jerry @ 2023-02-22 9:37 ` Jeffrey R.Carter 2023-02-22 9:49 ` Jerry 2023-02-22 14:26 ` Simon Wright 2023-02-22 9:39 ` Jerry 1 sibling, 2 replies; 17+ messages in thread From: Jeffrey R.Carter @ 2023-02-22 9:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-22 9:37 ` Jeffrey R.Carter @ 2023-02-22 9:49 ` Jerry 2023-02-22 14:26 ` Simon Wright 1 sibling, 0 replies; 17+ messages in thread From: Jerry @ 2023-02-22 9:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-22 9:37 ` Jeffrey R.Carter 2023-02-22 9:49 ` Jerry @ 2023-02-22 14:26 ` Simon Wright 2023-02-23 6:34 ` Jerry 1 sibling, 1 reply; 17+ messages in thread From: Simon Wright @ 2023-02-22 14:26 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-22 14:26 ` Simon Wright @ 2023-02-23 6:34 ` Jerry 2023-02-23 12:57 ` Niklas Holsti 0 siblings, 1 reply; 17+ messages in thread From: Jerry @ 2023-02-23 6:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-23 6:34 ` Jerry @ 2023-02-23 12:57 ` Niklas Holsti 2023-02-24 20:22 ` Jeffrey R.Carter 0 siblings, 1 reply; 17+ messages in thread From: Niklas Holsti @ 2023-02-23 12:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-23 12:57 ` Niklas Holsti @ 2023-02-24 20:22 ` Jeffrey R.Carter 0 siblings, 0 replies; 17+ messages in thread From: Jeffrey R.Carter @ 2023-02-24 20:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-22 8:50 ` Jerry 2023-02-22 9:37 ` Jeffrey R.Carter @ 2023-02-22 9:39 ` Jerry 2023-02-23 13:16 ` Simon Wright 1 sibling, 1 reply; 17+ messages in thread From: Jerry @ 2023-02-22 9:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-22 9:39 ` Jerry @ 2023-02-23 13:16 ` Simon Wright 2023-02-23 19:33 ` Jerry 0 siblings, 1 reply; 17+ messages in thread From: Simon Wright @ 2023-02-23 13:16 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-23 13:16 ` Simon Wright @ 2023-02-23 19:33 ` Jerry 2023-02-24 0:28 ` Jerry 0 siblings, 1 reply; 17+ messages in thread From: Jerry @ 2023-02-23 19:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-23 19:33 ` Jerry @ 2023-02-24 0:28 ` Jerry 2023-02-24 0:34 ` Jerry 0 siblings, 1 reply; 17+ messages in thread From: Jerry @ 2023-02-24 0:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-24 0:28 ` Jerry @ 2023-02-24 0:34 ` Jerry 2023-02-24 8:07 ` R R 0 siblings, 1 reply; 17+ messages in thread From: Jerry @ 2023-02-24 0:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-24 0:34 ` Jerry @ 2023-02-24 8:07 ` R R 2023-02-26 5:30 ` Jerry 0 siblings, 1 reply; 17+ messages in thread From: R R @ 2023-02-24 8:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Weird error emanating from GNAT binder: duplicat "gnatS" 2023-02-24 8:07 ` R R @ 2023-02-26 5:30 ` Jerry 0 siblings, 0 replies; 17+ messages in thread From: Jerry @ 2023-02-26 5:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-02-26 5:30 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-02-21 0:11 Weird error emanating from GNAT binder: duplicat "gnatS" Jerry 2023-02-21 22:59 ` Jerry 2023-02-22 5:53 ` Niklas Holsti 2023-02-22 8:50 ` Jerry 2023-02-22 9:37 ` Jeffrey R.Carter 2023-02-22 9:49 ` Jerry 2023-02-22 14:26 ` Simon Wright 2023-02-23 6:34 ` Jerry 2023-02-23 12:57 ` Niklas Holsti 2023-02-24 20:22 ` Jeffrey R.Carter 2023-02-22 9:39 ` Jerry 2023-02-23 13:16 ` Simon Wright 2023-02-23 19:33 ` Jerry 2023-02-24 0:28 ` Jerry 2023-02-24 0:34 ` Jerry 2023-02-24 8:07 ` R R 2023-02-26 5:30 ` Jerry
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox