alire

alire copied to clipboard

(This build is with aarch64-apple-darwin21 !!!, but I'm sure - without actually trying - that it'd be the same on x86_64. Found on alire tag 1.1.2, same on master)

I get the following (edited to only show the warnings)

gnatcoll-io-remote-windows.adb:496:36: warning: pragma Unreferenced given for "Status" [enabled by default]
gnatcoll-io-remote-unix.adb:409:36: warning: pragma Unreferenced given for "Status" [enabled by default]
gnatcoll-io-remote-unix.adb:434:36: warning: pragma Unreferenced given for "Status" [enabled by default]
gnatcoll-utils.adb:618:34: warning: pragma Unreferenced given for "Result" [enabled by default]
gnatcoll-io-remote.adb:851:62: warning: pragma Unreferenced given for "Dead" [enabled by default]
gnatcoll-scripts-shell.adb:38:06: warning: unnecessary with of ancestor [-gnatwr]
clic-command_line.adb:2244:40: warning: pragma Unreferenced given for "Success" [enabled by default]
clic-command_line.adb:2461:71: warning: pragma Unreferenced given for "Success" [enabled by default]
alire-roots.adb:113:29: warning: pragma Unreferenced given for "Was_There" [enabled by default]
alire-hashes.ads:80:07: warning: unused variable "Char" in conjunct [-gnatw.t]
alire-hashes.ads:80:07: warning: consider extracting conjunct from quantified expression [-gnatw.t]
alire-solutions.adb:396:12: warning: unused variable "Solved" in disjunct [-gnatw.t]
alire-solutions.adb:396:12: warning: consider extracting disjunct from quantified expression [-gnatw.t]
alire-properties-actions-executor.ads:1:06: warning: unnecessary with of ancestor [-gnatwr]
alire-toml_load.adb:177:10: warning: pragma Unreferenced given for "Pins" [enabled by default]
alr-last_chance_handler.adb:3:06: warning: unnecessary with of ancestor [-gnatwr]

   compilation of gnatcoll-io-remote.adb failed
   compilation of gnatcoll-scripts-shell.adb failed
   compilation of gnatcoll-utils.adb failed
   compilation of gnatcoll-io-remote-unix.adb failed
   compilation of gnatcoll-io-remote-windows.adb failed
   compilation of alire-toml_load.adb failed
   compilation of alire-properties-actions-executor.adb failed
   compilation of alire-solutions.adb failed
   compilation of alire-hashes.adb failed
   compilation of alire-roots.adb failed
   compilation of alr-last_chance_handler.adb failed

The gnatcoll problems arise because the Makefile defaults BUILD to PROD, but the GPR defaults it to DEBUG.

The pragma Unreferenced given for warnings are supposed to be fixed by changing the name of the variable that we are writing but not reading from Foo to Dummy or Unused (could that be Dummy_Foo or Unused_Foo?)

The warnings in e.g. alire-hashes.ads appear to be a genuine compiler problem: how is Char not used in

   function Is_Well_Formed (Hash_Img : String) return Boolean is
     (for some Char of Hash_Img => Char = ':' and then
      Is_Known (Utils.Head (Hash_Img, ':')));

We could build with -gnatw.T, turn off warnings for suspicious contract.

I got round all this by suppressing all info/warnings with

gprbuild -j0 -Palr_env -XOS=macOS -gnatws

I'm sure - without actually trying - that it'd be the same on x86_64

It is.

Thanks for the report, Simon.

Hi @mosteo

Just successfully built alr using the Build instructions from the repository's README.md, and using @simonjwright native Apple Silicon arm64 version of GNAT here: aarch64-apple-darwin21-2

Hit the same bug I think, with the following output:

   [Ada]          gnatcoll-io-remote-unix.adb
gnatcoll-io-remote-windows.adb:496:36: warning: pragma Unreferenced given for "Status" [enabled by default]
gnatcoll-io-remote-unix.adb:409:36: warning: pragma Unreferenced given for "Status" [enabled by default]
gnatcoll-io-remote-unix.adb:434:36: warning: pragma Unreferenced given for "Status" [enabled by default]

   compilation of gnatcoll-io-remote-unix.adb failed
   compilation of gnatcoll-io-remote-windows.adb failed

gprbuild: *** compilation phase failed

Used the suggested work around from Simon above, and instead built with: gprbuild -j0 -Palr_env -XOS=macOS -gnatws

All working now - so better get back to programming in Ada again, and using alr after a two years hiatus :)

% file ./alr 
alr: Mach-O 64-bit executable arm64

% ./alr version
APPLICATION                                               
alr version:            1.2.0-dev                         
libalire version:       1.2.0-dev                         
compilation date:       2022-04-01 14:48:59               
compiler version:       12.0.1 20220312 (experimental)    
                       
CONFIGURATION          
config folder:          /Users/simon/.config/alire        
force flag:             FALSE                             
non-interactive flag:   FALSE                             
community index branch: stable-1.1                        
indexes folder:         /Users/simon/.config/alire/indexes
indexes metadata:       OK                                
toolchain assistant:    enabled                           
tool #1 gnat:           not configured                    
tool #2 gprbuild:       not configured                    
                       
WORKSPACE              
root status:            VALID                             
root release:           alr=1.2.0-dev                     
root load error:        none                              
root folder:            /Users/simon/scratch/ada/alire    
current folder:         /Users/simon/scratch/ada/alire    
                       
SYSTEM                 
distribution:           DISTRO_UNKNOWN                    
host-arch:              ARCHITECTURE_UNKNOWN              
os:                     MACOS                             
target:                 NATIVE                            
toolchain:              USER                              
word-size:              BITS_64 

Used the suggested work around from Simon above, and instead built with: gprbuild -j0 -Palr_env -XOS=macOS -gnatws

I think -gnatwn (normal warning mode (cancels -gnatws/-gnatwe)) would have been better.

The warnings in e.g. alire-hashes.ads appear to be a genuine compiler problem: how is Char not used in

function Is_Well_Formed (Hash_Img : String) return Boolean is (for some Char of Hash_Img => Char = ':' and then Is_Known (Utils.Head (Hash_Img, ':')));

Turns out that what they want is to put the for some Char of Hash_Img => Char = ':' part in parens - makes sense if you think about it. I suppose conjunct, disjunct are terms of art in the formal methods world - see Wikipedia for conjunct.

Great news all around. I do wonder about the host-arch: ARCHITECTURE_UNKNOWN bit. What is the the output of uname -m in these machines?

Yes - definitely nice to know it is working 👍

A couple of uname outputs below for reference:

% uname -m 
arm64

# MacBook Pro (Apple M1 Pro)
% uname -a
Darwin cogentmoons.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000 arm64

# Mac mini (Apple M1)
% uname -a
Darwin minimoons.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:47:26 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T8101 arm64

There is also a few similar commands to uname -m - but not sure if they are unique to macOS though:

# outputs the same on Mac mini and MacBook Pro 
% machine
arm64e

% arch
arm64

They are both recently updated macOS systems:

% sw_vers 
ProductName:	macOS
ProductVersion:	12.3.1
BuildVersion:	21E258

Let me know if you need anything else :)

Thanks for that info, Simon. Indeed we do not have arm64 as a known architecture. Do you know if that would be equivalent to aarch64?

As far as I can see, arm64 is equivalent to aarch64.

So do we want to conflate both in our detection process?

Hi Alejandro

I am by no means an authority on ARM chipsets - but from what I understand they are both 'equivalent' as you suggest.

The aarch64 is generally the 64bit version of the ARM architecture, that came after the 32bit aarch32 equivalent.

The arm64 is Apple's version of that architecture, licensed from ARM, but adapted to suit Apple's needs.

I suppose Apple's arm64 just differentiates it from the existing aarch64 used in computers such as Raspberry Pi for example, Amazon Graviton, or Microsoft's use of SQ1 or SQ2 ARM processor in their Surface X computers, and so on. I think all those would be aarch64, but also known by the names: arm64; Graviton; SQ2; etc.

My understanding is that all ARM aarch64 processors would be the same 'equivalent' family - but have quite different features, capabilities and so on.

There is a better aarch64 explanation on Wikipedia aarch64 page. From an Apple perspective, there is also a Wikipedia Apple Silicon page that includes some M1 processor information too.

Apple has some specific information here: Writing ARM64 Code for Apple Platforms in case that is useful.

Simon

So do we want to conflate both in our detection process?

Sorry - my reply crossed over with your exchange with Fabien :)

If it helps - my view would be keep it simple, so no.

Showing aarch64 would be correct. The fact the alr version outputs also include os: MACOS would be enough to know it is and Apple computer using aarch64 vs a Raspberry Pi running Linux as aarch64 too.

Others might disagree, but I am sure it could be updated in the future if there was a strong enough argument to do different 👍

I would translate arm64 to aarch64, it's the standard name for this architecture.

Looks like Apple started they LLVM backend as arm64 but it was later merged with the "official" aarch64. This could explain their use of arm64 in uname.

See:

• https://stackoverflow.com/questions/31851611/differences-between-arm64-and-aarch64
• https://www.phoronix.com/scan.php?page=news_item&px=MTY5ODk
• https://github.com/llvm-mirror/llvm/commit/29f94c72014eaa5d0d3b920686e689e79759cacb

I see, thanks for the info Simon and Fabien. I'll fix our detection then, as I see no need to distinguish them.