From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Weird error emanating from GNAT binder: duplicat "gnatS" Date: Thu, 23 Feb 2023 13:16:15 +0000 Organization: A noiseless patient Spider Message-ID: References: <365f84cf-29ae-4857-8dfe-e3bfa2191f9dn@googlegroups.com> <022bbc8b-8764-4562-900a-7143fabd394cn@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader01.eternal-september.org; posting-host="212e44ea330652d7fb4499b4ba4dbf12"; logging-data="1983849"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX180ODKb16g01a4fSNQlWJ37bTSv0PiUK3U=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (darwin) Cancel-Lock: sha1:yhL1WdIsfmTPbh5pGJd0075MPqo= sha1:q7GTkSDMAJbhjeAu2ZtUitZQG94= Xref: reader01.eternal-september.org comp.lang.ada:64964 List-Id: Jerry 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).